DIP25 draft available for destruction

[deadalnix]

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.