DIP25 draft available for destruction

[Walter Bright]

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.