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.
