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

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

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.
}

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