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.
