27-Feb-2013 09:34, kenji hara пишет:
2013/2/27 deadalnix <[email protected] <mailto:[email protected]>>
>
> On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu
wrote:
>>
>> On 2/26/13 10:33 PM, kenji hara wrote:
>>>
>>> 2013/2/27 Jonathan M Davis <[email protected]
<mailto:[email protected]>
>>> <mailto:[email protected] <mailto:[email protected]>>>
>>>
>>> I believe that both Walter and Andrei have said on multiple
>>> occasions that one
>>> of C's big mistakes was conflating function names with their
>>> addresses, and
>>> this DIP appears to be trying to do exactly that. And I honestly
>>> don't see
>>> what it buys us. It just makes the situation with parenless function
>>> calls
>>> worse. At least right now, it's clear when you're dealing with a
>>> function
>>> pointer or a parenless function call. With this DIP, it wouldn't be.
>>>
>>>
>>> I agree with Jonathan. DIP27 is a recurrence of C's mistake.
>>> It would remove a language future, and breaking much existing code, and
>>> then introduces nothing. Certainly compiler implementation may be
>>> simplified a little by doing it, however it is too small benefit than
>>> the D world destruction.
>>>
>>> Kenji Hara
>>
>>
>> Agreed. I think it's safe to close it.
>>
>> Andrei
>
>
> Andrei, Kenji and Jonathan, can you explain what error of C did this
DIP reproduce and why it is an error ?
The mistake in C is mixing of function name and function address.
At least there is one ambiguity which appearance and meaning does not
correspond one-to-one.
And what is the advantage of plain function name over just _always_
having a (constant) pointer to it ?
Since a compiler can inline any "call by pointer" as long as it knows
it's a constant (like manifest constant in this DIP) performance and
codegen isn't an issue.
I'd say the mistake in C is to:
a) introduce nebulous type that's not expressible (plain function name).
b) make things subtly different for func and &func, and let the letter
be done under the covers sometimes
Killing both of these is an improvement.
In current D, the ambiguity is _already_ resolved - if you want to
function address, use & operator.
As far as I see, DIP27 will overturn the chess board, remove property
feature, change the meaning of 'foo', deprecate '&foo', and finally add
nothing for the language users.
--
Dmitry Olshansky
