DIP25 draft available for destruction

[deadalnix]

On Thursday, 7 February 2013 at 06:23:10 UTC, Walter Bright wrote:
> On 2/6/2013 10:13 PM, deadalnix wrote:
>> It is a given that @properties can't 100M emulate field, but 
>> the goal should be
>> to close he gap as much as possible.
>
> 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.

> 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, and a same identifier can 
refers to 3 different distinct (however related) concepts.

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.

>> 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 or a the other entity that have no 
name (the symbol resulting of a function declaration).

>
>> 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.