Is DMD 0.166 RC 1.0?

[Ivan Senji]

Walter Bright wrote:
> Derek Parnell wrote:
>>> 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.
> 
> Whether it's consistent or not depends on how you think about it - what 
> your mental model is of it. I'd rather have the odd cases produce error 
> messages rather than have the compiler paper over what is likely a 
> programmer oversight.

Hmm, inconsistent is: changing a field to a property -> some code 
doesn't need to change, some code needs to change.

It seems that your mental model is that properties and the result of 
opIndex/opIndexAssign behaving like normal lvalues is the odd case?
Well in my mental model them behaving like lvalues is a normal case, and 
the current behavior is a wtf.

Actually I would like to know what this sentence of yours means:
"If the user calls a function with a parameter that cannot accept such a 
return value, it is most likely a mistake."

Does it mean if a property is passed that doesn't have a setter method? 
I would expect that to be reported at compile time as a nice "cannot 
pass read-only property as lvalue".

Is there an example where replacing

f(a.prop);

with

auto x=a.prop; f(x); a.prop=x;

would be a bad thing to do, and could result in unexpected code, or hard 
to catch bugs.
Sure some aspects of this behavior should be well documented to avoid 
confusion (like the fact that the value is updated on function exit) but 
it is the same with most other feature.

To make myself clear: D can do without this feature but without it a simple:

write f(a.prop) -> compile&run happily

is replaced with

write f(a.prop) -> compile -> goto line with error -> figure out the 
error and how to fix it (might be hard the first time) ->
select "f(a.prop)" -> Ctrl-X -> write auto x=a.prop; f(x); a.prop=x; ->
compile&run (but less happily now)