On Mon, Mar 31, 2014 at 09:55:01PM +0000, monarch_dodra wrote:
> On Monday, 31 March 2014 at 21:41:16 UTC, H. S. Teoh wrote:
> >Argh, why is opSlice non-const? :-(  Please file a bug.
> 
> If opSlice was const, then you'd get a const slice, with const reference.  You wouldn't even be able to iterate on it.
[...]

Um... wat?

I didn't say opSlice should return a const object (that would be ridiculous, as you point out). Rather, it should return a tail-const range that iterates over the const items in the const list.

A const container that cannot be iterated over makes no sense at all. Iterating over something doesn't modify anything!!


T

-- 
Ruby is essentially Perl minus Wall.

Still no luck:

import std.container;
import std.stdio;

void main()
{
	DList!ubyte list1 = DList!ubyte();
	list1 ~= cast(ubyte) 1;
	list1 ~= cast(ubyte) 2;
	list1 ~= cast(ubyte) 3;

	foreach(ubyte item; list1[]) {
		writeln(item);
	}
}

/usr/include/dlang/dmd/std/container.d(1874): Error: no property '_first' for type 'ubyte'
/usr/include/dlang/dmd/std/container.d(1875): Error: no property '_first' for type 'ubyte'
/usr/include/dlang/dmd/std/container.d(1875): Error: undefined identifier rhs_, did you mean variable rhs?
source/app.d(7): Error: template instance std.container.DList!ubyte.DList.opOpAssign!("~", ubyte) error instantiating
source/app.d(7): Error: cannot append type ubyte to type DList!ubyte

On Tuesday, 1 April 2014 at 04:43:44 UTC, H. S. Teoh wrote:
> On Mon, Mar 31, 2014 at 09:55:01PM +0000, monarch_dodra wrote:
>> On Monday, 31 March 2014 at 21:41:16 UTC, H. S. Teoh wrote:
>> >Argh, why is opSlice non-const? :-(  Please file a bug.
>> 
>> If opSlice was const, then you'd get a const slice, with const
>> reference.  You wouldn't even be able to iterate on it.
> [...]
>
> Um... wat?

I'm pointing out the fix is not as trivial as slapping "const" onto the signature. It requires a very real investment in terms of development.

> I didn't say opSlice should return a const object (that would be
> ridiculous, as you point out). Rather, it should return a tail-const
> range that iterates over the const items in the const list.

Yes.

> A const container that cannot be iterated over makes no sense at all.
> Iterating over something doesn't modify anything!!

Yes.

On 03/31/2014 10:32 PM, Jeroen Bollen wrote:
> Still no luck:
>
> import std.container;
> import std.stdio;
>
> void main()
> {
>      DList!ubyte list1 = DList!ubyte();
>      list1 ~= cast(ubyte) 1;
>      list1 ~= cast(ubyte) 2;
>      list1 ~= cast(ubyte) 3;
>
>      foreach(ubyte item; list1[]) {
>          writeln(item);
>      }
> }
>
> /usr/include/dlang/dmd/std/container.d(1874): Error: no property
> '_first' for type 'ubyte'
> /usr/include/dlang/dmd/std/container.d(1875): Error: no property
> '_first' for type 'ubyte'
> /usr/include/dlang/dmd/std/container.d(1875): Error: undefined
> identifier rhs_, did you mean variable rhs?
> source/app.d(7): Error: template instance
> std.container.DList!ubyte.DList.opOpAssign!("~", ubyte) error instantiating
> source/app.d(7): Error: cannot append type ubyte to type DList!ubyte

I think your problem is fixed in a more recent compiler. The code works with git head dmd but fails with e.g. 2.064. (Not tested with 2.065.)

Ali

On Tuesday, 1 April 2014 at 10:56:40 UTC, Ali Çehreli wrote:
> On 03/31/2014 10:32 PM, Jeroen Bollen wrote:
>> Still no luck:
>>
>> import std.container;
>> import std.stdio;
>>
>> void main()
>> {
>>     DList!ubyte list1 = DList!ubyte();
>>     list1 ~= cast(ubyte) 1;
>>     list1 ~= cast(ubyte) 2;
>>     list1 ~= cast(ubyte) 3;
>>
>>     foreach(ubyte item; list1[]) {
>>         writeln(item);
>>     }
>> }
>>
>> /usr/include/dlang/dmd/std/container.d(1874): Error: no property
>> '_first' for type 'ubyte'
>> /usr/include/dlang/dmd/std/container.d(1875): Error: no property
>> '_first' for type 'ubyte'
>> /usr/include/dlang/dmd/std/container.d(1875): Error: undefined
>> identifier rhs_, did you mean variable rhs?
>> source/app.d(7): Error: template instance
>> std.container.DList!ubyte.DList.opOpAssign!("~", ubyte) error instantiating
>> source/app.d(7): Error: cannot append type ubyte to type DList!ubyte
>
> I think your problem is fixed in a more recent compiler. The code works with git head dmd but fails with e.g. 2.064. (Not tested with 2.065.)
>
> Ali

doesn't work on 2.065

John Colvin:

> doesn't work on 2.065

But it works in the latest alpha.

Bye,
bearophile

On Tuesday, 1 April 2014 at 10:56:40 UTC, Ali Çehreli wrote:
> On 03/31/2014 10:32 PM, Jeroen Bollen wrote:
>> Still no luck:
>>
>> import std.container;
>> import std.stdio;
>>
>> void main()
>> {
>>     DList!ubyte list1 = DList!ubyte();
>>     list1 ~= cast(ubyte) 1;
>>     list1 ~= cast(ubyte) 2;
>>     list1 ~= cast(ubyte) 3;
>>
>>     foreach(ubyte item; list1[]) {
>>         writeln(item);
>>     }
>> }
>>
>> /usr/include/dlang/dmd/std/container.d(1874): Error: no property
>> '_first' for type 'ubyte'
>> /usr/include/dlang/dmd/std/container.d(1875): Error: no property
>> '_first' for type 'ubyte'
>> /usr/include/dlang/dmd/std/container.d(1875): Error: undefined
>> identifier rhs_, did you mean variable rhs?
>> source/app.d(7): Error: template instance
>> std.container.DList!ubyte.DList.opOpAssign!("~", ubyte) error instantiating
>> source/app.d(7): Error: cannot append type ubyte to type DList!ubyte
>
> I think your problem is fixed in a more recent compiler. The code works with git head dmd but fails with e.g. 2.064. (Not tested with 2.065.)
>
> Ali

I fixed this not too long ago. Long story short, the "~=" implementations were made of fail.

Just change those "~=" for "insertBack" and you should be fine.

On Tuesday, 1 April 2014 at 12:30:03 UTC, monarch_dodra wrote:
> I fixed this not too long ago. Long story short, the "~=" implementations were made of fail.
>
> Just change those "~=" for "insertBack" and you should be fine.

That aside, why is it necessary to cast 1, 2 and 3 to ubyte when adding them to the DList? Is this a problem with DList or with D?

On Tue, 01 Apr 2014 09:30:18 -0400, Meta <jared771@gmail.com> wrote:

> On Tuesday, 1 April 2014 at 12:30:03 UTC, monarch_dodra wrote:
>> I fixed this not too long ago. Long story short, the "~=" implementations were made of fail.
>>
>> Just change those "~=" for "insertBack" and you should be fine.
>
> That aside, why is it necessary to cast 1, 2 and 3 to ubyte when adding them to the DList? Is this a problem with DList or with D?

A limitation with D.

The issue is that IFTI interprets numeric literals as type int. There simply is no way to say "if you get a numeric literal that fits within a ubyte, use ubyte as the type for T"

See this bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4998

-Steve

On Tuesday, 1 April 2014 at 13:30:21 UTC, Meta wrote:
> On Tuesday, 1 April 2014 at 12:30:03 UTC, monarch_dodra wrote:
>> I fixed this not too long ago. Long story short, the "~=" implementations were made of fail.
>>
>> Just change those "~=" for "insertBack" and you should be fine.
>
> That aside, why is it necessary to cast 1, 2 and 3 to ubyte when adding them to the DList? Is this a problem with DList or with D?

D has a "feature", where you can't assign something big into something small. EG, you can't assign an int to a byte. This avoids dangerous overflow.

That said, this is *usually* transparent, because D *also* has value range analysis. So what this means is that when you write:
"ubyte b = 1;"
Even though "1" is actually an int, the compiler knows it is int he 0-255 range, so the assignment is fine.

In contrast, if you *pass* "1" to the DList, you lose that info, and the DList will complain that you are trying to assign an int to a ubyte.

For what it's worth, 2.066 introduces uniform initialization, so this will become valid, and is somewhat less intrusive:

    list1.insertBack(ubyte(1));
    list1.insertBack(ubyte(2));
    list1.insertBack(ubyte(3));