DIP25 draft available for destruction

[Walter Bright]

On 2/7/2013 12:22 AM, deadalnix wrote:
>> Ok, why should "as much as possible" be the goal? There are other
>> considerations - what merit should they have?
> I don't think anyone have interest to get back on that. If you have another
> answer to that question, please share.


The point is, there must always be a balance of competing interests. That's 
certainly true here.



>> For example, I consider having an easily understood mental model of how things
>> work to be very important. Having the language doing mysterious heroic things
>> under the hood trying to implement someone else's idea of human intuition
>> impairs anyone's ability to understand a language.
>>
>
> Ease come from 2 main things :
>   - Fit the mental model that an user have in realted area (ie other programing
> languages)
>   - Simplicity (which is very different from ease).
>
> The current proposal seems easy to you because it is close o YOUR mental model,
> working on D. But on a larger scale, it fails at both criteria mentioned above :
> it is different from what exists in any languages mentioned in this NG,

Does C# always allow taking the address of a getter's return value? I don't 
know, but I'd be surprised if it did.


> and a same identifier can refers to 3 different distinct (however related) concepts.

It is not unusual for an identifier to mean different things in different 
constructs.


> DIP25 aim to solve the ref issue. Which is clearly useful. Conflating that goal
> with making previous DIP on function call is only going to export the mess in
> another area of the language.
>
> This is the very example of why simplicity in semantic is key.

Simplicity is great, but it does not always trump everything else. It's also 
possible for reasonable people to disagree on what is simple or intuitive.



>>> It doesn't change anything in many cases. Especially for template alias
>>> parameters.
>>
>> Why? foo seems straightforward as a template alias parameter, meaning the
>> function foo. Alias parameters do not take expressions as arguments - so the
>> expression rules do not apply.
>>
>
> An alias template parameter bind to a symbol. A symbol can be either a
> first-class function

Yes.

> or a the other entity that have no name (the symbol resulting of a function declaration).

Yes. But I don't see the issue. &foo cannot bind to an alias parameter, nor can 
foo().


>>> It doesn't change the intrinsic complexity of the proposal that
>>> conflate a function (as first class object), its return value, and the useless
>>> C/C++ entity that is a function.
>>
>> Removing an ambiguous case does reduce the intrinsic complexity.
>
> I'm sure that, as a developer that specialized itself in compilers, you
> perfectly know the difference between syntax and semantic. And that solving a
> syntax issue that is symptom of a semantic issue will not fix the semantic issue.

What &foo means is a semantic issue, not a syntactic one. It's not an ambiguous 
grammar. Semantic ambiguity issues are resolved by creating rules (which one may 
consider intuitive or arbitrary) and applying them, which is what we're doing here.

There are several such ambiguities in D that are resolved by applying semantic 
disambiguation rules. This is done because although it makes the spec (and the 
compiler) more complex, it is actually simpler for the user.

Saying that one cannot take the address of a return value solves the semantic 
ambiguity problem with &foo.