On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
The point is, there must always be a balance of competing
interests. That's certainly true here.
That is an assertion not an argument.
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.
C# don't have address of. It isn't a system language. Even if you
consider the whole stuff without the address problem, the D way
is different than C#'s. The 'funny' things is that C#'s would
cause syntax problem issue with address of, where D does.
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.
Usually not when they resolve to the same symbol. And it has to
be proven that this is a good thing.
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.
Here we have a more complex solution, and more problem with it.
Conclude whatever you want, but each time I choose the complex
path in my programmer life, I ended up with that kind of effect.
You also seems to conflate simple and intuitive, which are really
unrelated. Simplicity is mostly objective, when intuition is
mostly subjective. Both combined usually lead to ease.
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().
void function() foo can.
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.
You should hear ambiguous as ambiguous for the parser here. This
is possible to make any crazy insane syntax unambiguous for the
parser.
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.
I don't think it is, and looking at other languages choices, I'm
not alone.
This kind of thing always seems simple of some cases, but ends up
creating a huge minefield of special case when you start to
combine feature together. And this is something that most D users
experiences.
It result in users not using advanced D features (see HIGGS topic
for instance, or many codebases on github in general) or user
having trouble. It is often advised to stay away form advanced
features of D for production quality stuff and I have to say I
share the observation. Working on large codebase (well large . .
. for a personal project, but clearly ridiculous compared to many
companies codebase : ~25 000LOC) using advanced features of D, I
run in such troubles almost on a daily basis, and have developed
some knowledge of area of the language I should not even try to
go in.
