Is DMD 0.166 RC 1.0?

[Chris Nicholson-Sauls]

Oskar Linde wrote:
> 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; } ?
> 

Easy enough, return a pointer to the struct.

But still.

-- Chris Nicholson-Sauls