www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - writeln, alias this and dynamic arrays.

reply matthewh <matthew.hanham gmail.com> writes:
I am new to D and have been fiddling with bits and pieces.
I have this code:

import std.stdio : writeln;
import std.format : format;

class Base
{
     override
     {
         //string toString()
         //{
          //   return format("%s", store);
         //}
     }
     ubyte[] store;
     alias store this;
     this()
     {
         store = [1, 2, 3, 4, 5, 6, 7, 8];
     }
}

class Top
{
     Base store;
     alias store this;
     this()
     {
         store = new Base;
     }
}

void main()
{
     auto f = new Top;
     writeln(f.store);
     writeln(f.store);
}

as is it produces:

[1, 2, 3, 4, 5, 6, 7, 8]
[]

I expected it to produce:

[1, 2, 3, 4, 5, 6, 7, 8]
[1, 2, 3, 4, 5, 6, 7, 8]

And with the toString override included it does.

Why does the version without the toString override output an 
empty array?

Thank you.
Nov 16
next sibling parent reply Michael V. Franklin <slavo5150 yahoo.com> writes:
On Friday, 17 November 2017 at 02:13:54 UTC, matthewh wrote:

 And with the toString override included it does.

 Why does the version without the toString override output an 
 empty array?
I think that is due to this bug: https://issues.dlang.org/show_bug.cgi?id=13189 It's actually on my todo list to fix, but I'm not sure yet if its within my current abilities. Mike
Nov 16
parent Michael V. Franklin <slavo5150 yahoo.com> writes:
On Friday, 17 November 2017 at 02:16:35 UTC, Michael V. Franklin 
wrote:
 On Friday, 17 November 2017 at 02:13:54 UTC, matthewh wrote:

 And with the toString override included it does.

 Why does the version without the toString override output an 
 empty array?
I think that is due to this bug: https://issues.dlang.org/show_bug.cgi?id=13189 It's actually on my todo list to fix, but I'm not sure yet if its within my current abilities.
Actually, after playing with your example, I don't think that's the case. There's something else going on, and I'm not sure what it is. It's a strange error indeed. Mike
Nov 16
prev sibling parent reply Michael V. Franklin <slavo5150 yahoo.com> writes:
On Friday, 17 November 2017 at 02:13:54 UTC, matthewh wrote:
 [...]
 as is it produces:

 [1, 2, 3, 4, 5, 6, 7, 8]
 []

 I expected it to produce:

 [1, 2, 3, 4, 5, 6, 7, 8]
 [1, 2, 3, 4, 5, 6, 7, 8]

 And with the toString override included it does.

 Why does the version without the toString override output an 
 empty array?
Actually, it looks like it's this 4-year old bug. https://issues.dlang.org/show_bug.cgi?id=9506 So frustrating :( Mike
Nov 16
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 17 November 2017 at 06:57:16 UTC, Michael V. Franklin 
wrote:
 Actually, it looks like it's this 4-year old bug.  
 https://issues.dlang.org/show_bug.cgi?id=9506
Yeah, I suspected this is old and my comment in there still applies... It passes the isInputRange test due to the implicit conversion of alias this, and then writeln takes it and consumes it. One thing you might consider is making the alias this go to a getter property instead of the method directly. Then operations on it will work on a copy of the slice, and thus not consume the original one. But then you can't do stuff like append do it directly either... imo writeln should check for .save and use it. But meh I don't care to personally bother fixing it and apparently nobody else does either.
Nov 17
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/17/17 8:13 AM, Adam D. Ruppe wrote:
 On Friday, 17 November 2017 at 06:57:16 UTC, Michael V. Franklin wrote:
 Actually, it looks like it's this 4-year old bug. 
 https://issues.dlang.org/show_bug.cgi?id=9506
Yeah, I suspected this is old and my comment in there still applies... It passes the isInputRange test due to the implicit conversion of alias this, and then writeln takes it and consumes it.
In doing some digging, I found that it actually calls the object version of formatValue. Which is specifically written to check if Object.toString has been overridden. If not, and it has a range interface, it treats it as a range. So this is not a bug. By using alias this against a range, you have turned it into a range interface.
 One thing you might consider is making the alias this go to a getter 
 property instead of the method directly. Then operations on it will work 
 on a copy of the slice, and thus not consume the original one. But then 
 you can't do stuff like append do it directly either...
It doesn't work, I tried that. The reason is because, for arrays, popFront requires an lvalue (obviously), and so isInputRange for such a class is false. It just prints the class name, like a normal class. Ironically, alias this to a struct range type (like say filter), would be even more disastrous: class C(R) { R foo; R getFoo() { return foo; } alias getFoo this; } auto f = [1, 2, 3, 4].filter!"a & 1"; auto c = new C!(typeof(f)); c.foo = f; writeln(c);// [1, 1, 1, 1, 1, 1,.... This is because C.getFoo.popFront works, even though it's an rvalue! I don't think there's a way to figure out this situation and properly deal with it. My recommendation is basically, don't do this. It's not going to work like you expect.
 imo writeln should check for .save and use it. But meh I don't care to 
 personally bother fixing it and apparently nobody else does either.
.save isn't even properly implemented. It must return the same type as the original. e.g.: static assert(!isForwardRange!C); Jonathan has talked about this, and I agree with him. The only real way to fix forward ranges is to get rid of save, and make copyability the thing that makes a forward range a forward range. But that's not going to happen, too disruptive. -Steve
Nov 17
parent matthewh <matthew.hanham gmail.com> writes:
Thank you all for the helpful responses.
I will read more about ranges.
Nov 22