Is DMD 0.166 RC 1.0?

[Oskar Linde]

Derek Parnell wrote:
> On Mon, 04 Sep 2006 10:42:19 -0700, Walter Bright wrote:
> 
>> Ivan Senji wrote:
>>> Maybe not the right time to mention it but: one of the most annoying 
>>> error messages dmd produces is "is not an lvalue". An annoying message 
>>> isn't doesn't make a good first impression, and it makes an even worse 
>>> second or third impression.
>>>
>>> Example:
>>>
>>>   class A
>>>   {
>>>     int xx = 11;
>>>     int opIndex(int pos){return xx;}
>>>     int opIndexAssign(int what, int pos){return xx = what;}
>>>
>>>     int prop(){return xx;}
>>>     int prop(int newxx){return xx = newxx;}
>>>   }
>>>
>>>   auto a = new A;
>>>
>>>   void f(inout int x)
>>>   {
>>>     x ++;
>>>   }
>>>
>>>   f(a[5]);    //((a).opIndex)(5) is not an lvalue
>>>   f(a.prop);  //((a).prop)() is not an lvalue
>>>
>>> Maybe a[5] isn't strictly an lvalue because it's adress can't be taken 
>>> but, it would make much sense for the compiler to translate those cases 
>>> to (and shouldn't be that hard to do):
>>>
>>> auto x = a[5];
>>>   f(x);
>>> a[5] = x;
>>>
>>> auto y = a.prop;
>>>   f(y);
>>> a.prop = y;
>>>
>>> I don't want to sound lika a D-hater because of my recent (complaining) 
>>> posts but just trying to show that although D is a fantastic language it 
>>> is still a little too rough around the edges.
>> The compiler can translate those cases, but I feel that would be the 
>> wrong thing to do. If a function has inout for a parameter, it means 
>> that the function is expected to essentially return a value through the 
>> parameter. If the user calls a function with a parameter that cannot 
>> accept such a return value, it is most likely a mistake. If the compiler 
>> rewrites the code so it "works", then it's probably going to make 
>> finding the bug difficult.
>>
>> It's an error in C++ for the same reason (can't initialize a reference 
>> with a non-const).
> 
> You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
> In fact, it could have been one until the class author changed it to a
> property.  I feel that Properties need to behave as if they were data
> members rather than methods when used as such. Thus ...
> 
>   f(a.prop);
> and
>   f(a.prop());
> 
> would look *and* behave differently but without surprising the coder.
> 
> And this also means that 
> 
>   a.prop++
> 
> needs to work too. It is a great surprise to new comers that obvious things
> like this are not working as expected.
> 

And what about:

a.prop.y = 7;

Where prop is/returns a struct { int x,y; } ?

-- 
Oskar