DIP25 draft available for destruction

[deadalnix]

On Thursday, 7 February 2013 at 10:32:38 UTC, Walter Bright wrote:
> 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.
>

Ho yeah, I'm not arguing against that. But what is seen as 
conflicting goal often aren't.

>>> 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.
>

In C#, foo.bar won't execute bar's method of foo. It will get 
what is called in D a delegate. foo.bar() execute that delegate.

It remove the need for &foo.bar altogether, so with that 
mechanism in D, no problem with & operator.

Scala does even one step further by executing the method, or not, 
depending on what is expected, proving that optional () are 
compatible with.

Back to D, we have void function() foo; foo is declared as a 
function here. However, void bar() {} will also be called a 
function, even if the entity represented by foo and bar are 
completely different.

When you do foo = &bar, you get a pointer on foo's instruction. 
Here foo isn't a function in the D sense, but an Array of CPU 
instruction, or something like that. This entity, coming from 
C/C++ hasn't ANY useful usage except taking the address of to get 
a function. Wanting to keep that useless entity is the source of 
most trouble with the & syntax, and also on previous DIP (not 
that one).

> How does one prove anything is a "good thing"?
>

Proven may be strong, but you can't refute that some things are 
better than others.

>>> 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.
>

Now you can pass several object to templates alias parameters, 
that will behave differently in slightly different subtle ways. 
For no real good reason.

>> 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.
>

If A is the instruction pack entity type mentionned above, you'll 
find pretty hard to find a !A if we exclude C and C++ (well and 
D, but it is kind of excluded if look for references). I don't 
pretend none exists, but it seems pretty hard to find one.

Because the idea is bad for everybody : it make the language more 
complex, harder to implement compiler/tooling for, can conflict 
with other features, and worse, have no benefice.

This is a bad idea in all possible way. Actually so bad that even 
PHP don't implement it.

>> 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.
>

He does so by adding special cases. That is the problem with 
special cases, they multiply themselves faster than rabbits.

>> 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.

It is clear that the property improvement proposed by Andrei is a 
great step forward. However, the &foo.bar that return the 
delegate when bar is a property is exactly the kind of stuff that 
are waiting to explode.

Yes, this DIP remove the syntactic ambiguity (does this take the 
delegate or the address of the result ?) but that is barely it. 
I'd say that the fact that & have a meaning is way more 
problematic than the fact that it is not possible to take the 
resulting address.