DIP27 available for destruction

[kenji hara]

2013/2/27 deadalnix <deadalnix at gmail.com>

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

In D, function symbol and function pointer are distinct entities. The
former is just accessible by its name and it has _no_ runtime value. The
latter is a runtime value which generated by applying address operator to
function symbol.

Also in C, essentially these entities are distinct, but C's semantic
analyzer will implicitly apply address operator against the use of function
name. Finally 'foo' has the same meaning as '&foo'. That has still
introduced confusion to many programmer's.

Back to D, the two entities explicitly separated syntactically, and the use
of function name is newly assigned as 'property call' (note that, the
definition of 'property' is still debatable). So, applying DIP27 is just
equivalent to discarding property feature.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130227/349298eb/attachment-0001.html>