Is DMD 0.166 RC 1.0?

[Derek Parnell]

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.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"