DIP23 draft: Fixing properties redux

[Andrei Alexandrescu]

On 2/5/13 4:35 PM, Zach the Mystic wrote:
> On Tuesday, 5 February 2013 at 20:24:16 UTC, Andrei Alexandrescu wrote:
>>> I hope it at least considers my proposal with regard to 'out' return
>>> values. 'out' implies ref and guarantees that the result is as good as
>>> global:
>>>
>>> out int foo(ref int a) { return a; } // Error, 'out' return may not
>>> return ref parameter
>>> out int goo(ref int a) { return new int; } // Fine
>>>
>>> My impression was that this would solve 98% of problems, the other 2%
>>> requiring scope parameters, which also imply ref:
>>>
>>> ref int haa(ref int a, scope int b) { return b; } // Error, may not
>>> return scope parameter
>>> ref int gaa(ref int a, scope int b) { return a; } // Fine
>>
>> I'm sorry, I didn't know of that proposal. Generally we're aiming for
>> economy of means i.e. we want to clarify semantics of existing syntax
>> instead of adding new syntax and semantics.
>>
>> Andrei
>
> It's not a new syntax, just new semantics. Also, the reason for adding
> these semantics to the function signature was so that the compiler would
> never have to leave the function in order to compile it. It's a natural
> complement to ref returns' scope being the most local of the ref
> parameters, which you suggested in your proposal. It keeps that too.

Just to make sure: this is about 
http://forum.dlang.org/thread/ririagrqecshjljcdubd@forum.dlang.org.

Language design is a subjective topic. With time I have learned it's 
best to not comment very much about it. I have created dozens, maybe 
hundreds of tidbits of language design and invariably I believe they had 
obvious merits and negligible drawbacks. The confidence in the quality 
of my own language designs has decayed exponentially over the years.

I'm telling this to put in perspective my following comment. I think 
it's awesome that work like yours is discussed and refined in this 
group. At the same time my opinion is that the design is not appropriate 
for us. It changes semantics of existing code and fosters a cross-talk 
between subcomponents that has not been time tested. It is complicated 
in implementation for a benefit that's not properly motivated. At the 
top level it solves the wrong problem. As stated: "The challenge is to 
do better, both in terms of functionality and in terms of syntax, than 
his proposal: ..." The actual challenge is to make properties work with 
maximum backward compatibility, minimal surprise, best integration with 
the rest of the language, and maximum of benefits.


Andrei