Is DMD 0.166 RC 1.0?
Chad J
gamerChad at _spamIsBad_gmail.com
Mon Sep 4 15:15:37 PDT 2006
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; } ?
>
I'm not a fan of the current property syntax either. I'd be very happy
to see Walter implement get/set syntax, or some such. I just can't say
this is a 1.0 issue though, unless it's going to be tough to rewrite
code when it's changed.
Are there plans to change this in the future?
More information about the Digitalmars-d-announce
mailing list