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/[email protected].
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
