On 2/7/2013 2:05 AM, deadalnix wrote:
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.
Try designing anything by using one overriding principle - you won't get a
useful result. Designs are always tradeoffs, always.
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.
It's a different language, with a different view of things. Direct comparisons
between D and C# need to take that into account.
The 'funny' things is that C#'s would cause syntax problem issue with address
of,
where D does.
I don't understand this sentence.
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.
How does one prove anything 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,
Not really, I said "simple OR intuitive" :-)
Yes. But I don't see the issue. &foo cannot bind to an alias parameter, nor
can foo().
void function() foo can.
Sure. But I'm lost at what your point is with that example.
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.
Given the vast variety and complexity of languages out there, for every example
of A you can find, I can find examples of !A. It's not really useful, after all,
if other languages got it all right, there's no point to D.
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.
I believe that Andrei's proposal resolves these.
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.
This is exactly why we're going through this exercise with the properties.
