www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Member-assignment for std.container.Array!Struct

reply Matthias Walter <xammy xammy.info> writes:
Hi,

about 2 years ago I stopped using D for my projects since there were too
many bugs that hindered me from making quick progress. Since I got
several mails from bugzilla about those bugs being fixed I wanted to
give it another try. Unfortunately, the following non-working code made
me think to stop using it once again:

struct S
{
  int i;
}
Array!S array = [ S(0) ];
array[0].i = 1;

The reason is certainly that the change only affects a copy and not the
true array-member. I remember that there was a discussion about sealed
containers and returning references, etc.

My question is now: Has there been any progress in this direction? I
know that the design of ref's semantics is a nontrivial topic, but on
the other hand in my opinion std.container.Array is completely useless
if not even the above code works as one would expect!

Best regards,

Matthias
Jan 09 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/9/14 11:36 PM, Matthias Walter wrote:

 Hi,

 about 2 years ago I stopped using D for my projects since there were too
 many bugs that hindered me from making quick progress. Since I got
 several mails from bugzilla about those bugs being fixed I wanted to
 give it another try. Unfortunately, the following non-working code made
 me think to stop using it once again:

 struct S
 {
    int i;
 }
 Array!S array = [ S(0) ];
 array[0].i = 1;

 The reason is certainly that the change only affects a copy and not the
 true array-member. I remember that there was a discussion about sealed
 containers and returning references, etc.

 My question is now: Has there been any progress in this direction? I
 know that the design of ref's semantics is a nontrivial topic, but on
 the other hand in my opinion std.container.Array is completely useless
 if not even the above code works as one would expect!


It's an outrage, and this particular combination of (mis)features has 
never got to my attention until now.

I've submitted https://d.puremagic.com/issues/show_bug.cgi?id=11889 on 
your behalf. I've also sent out the fix 
https://github.com/D-Programming-Language/phobos/pull/1845 for review. 
(It's simple, but perhaps I'm missing some subtler issues.)

Apologies for this!


Andrei
Jan 10 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 10 January 2014 at 08:27:42 UTC, Andrei Alexandrescu 
wrote:

 It's an outrage, and this particular combination of 
 (mis)features has never got to my attention until now.

 I've submitted 
 https://d.puremagic.com/issues/show_bug.cgi?id=11889 on your 
 behalf. I've also sent out the fix 
 https://github.com/D-Programming-Language/phobos/pull/1845 for 
 review. (It's simple, but perhaps I'm missing some subtler 
 issues.)

 Apologies for this!


 Andrei


Array returns a value by design. I don't think it's array that's 
wrong here, it's being able to assign to members of an rvalue 
(IMO).

Off the top of my head, a possible language enhancement would be 
to allow member functions to be marked as "ref", in which case, 
they only work on lvalue (as applying the function on a temp 
would make no sense).

eg:
struct S
{
     void doit();
     void opAssign(int) ref;
}

void main()
{
     S().doit(); //OK, rvalue call
     S() = 5; //Nope, opAssign requires an lvalue.
}
Jan 10 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/14 12:53 AM, monarch_dodra wrote:

 On Friday, 10 January 2014 at 08:27:42 UTC, Andrei Alexandrescu wrote:

 It's an outrage, and this particular combination of (mis)features has
 never got to my attention until now.

 I've submitted https://d.puremagic.com/issues/show_bug.cgi?id=11889 on
 your behalf. I've also sent out the fix
 https://github.com/D-Programming-Language/phobos/pull/1845 for review.
 (It's simple, but perhaps I'm missing some subtler issues.)

 Apologies for this!


 Andrei


 Array returns a value by design.


It's my design. The rationale for returning by value has since vanished. 
The idea was to make impossible to take addresses of elements inside 
containers (I still plan to write an article "sealed containers" at some 
point). However, Walter and I decided to ban taking the address of ref 
returns since (currently not enforced).

Andrei
Jan 10 2014