DIP25 draft available for destruction

[Walter Bright]

On 2/7/2013 3:16 AM, deadalnix wrote:
>>> 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.

No, that declares foo as a "pointer to function".


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

They won't behave any differently than they would outside of being passed as 
aliases. I don't see a special problem added with alias parameters.


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

There are few languages in the systems programming category (languages that give 
one full access to pointers), so excluding C and C++ seems rather draconian.


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

Taking the address of a ref was already problematic.