Is DMD 0.166 RC 1.0?

[Ivan Senji]

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.

Hmm, I'm going to have to look into it a little bit further. I 
understand the potential problems with the compiler converting this. But 
isn't also a change from a field to a property that breaks existing code 
also a problem (maybe even a bigger one)? This has happened to me more 
than once.

Inout means return a value through the param? I agree, but it is a 
limitation that it cannot be returned into property.

The compiler could always issue a nice warning message if read or write 
property is missing.

> 
> It's an error in C++ for the same reason (can't initialize a reference 
> with a non-const).