DIP27 available for destruction

[Maxim Fomin]

On Wednesday, 27 February 2013 at 07:26:47 UTC, deadalnix wrote:
> On Wednesday, 27 February 2013 at 06:15:29 UTC, dennis luehring 
> wrote:
>> Am 27.02.2013 06:54, schrieb deadalnix:
>>>> In current D, the ambiguity is _already_ resolved - if you 
>>>> want
>>>> to function
>>>> address, use & operator.
>>>>
>>>
>>> D behave very much like C on that regard, so I don't really 
>>> see
>>> how this can be true.
>>
>> void (*functionPtr)();
>>
>> //both are valid and working in C
>> functionPtr xyz = &foo;
>> functionPtr zxy = foo; //<- this is solved in D
>
> I don't think D solved that. Only partially. Both are conflated 
> here for instance :
>
> void foo() {}
> foo(); <=> (&foo)();
>
> Is another presentation of the same conflation.
>
> The DIP propose to effectively solve that by removing 
> completely the entity represented by foo in &foo . You can't 
> have conflation with something that do not exists.

No, in D there is no conflation between this two. The fact that 
you write (&foo)() instead of foo() (if foo is pointer) says 
about it.

What Andrei, Kenji and Jonathan try to say (I guess) that 
function type in C in all cases is implicitly convertible to 
function pointer except when it is used with sizeof, Alignof and 
& operators (iso/iec $6.3.2). This is among the first differences 
I noticed when came from C.

If such implicit conversion is performed in D, taking into 
account D complexity and corner cases may lead to collisions on 
using function name - is it a pointer or a type?