DIP27 available for destruction

[Dmitry Olshansky]

27-Feb-2013 09:34, kenji hara пишет:
> 2013/2/27 deadalnix <deadalnix at gmail.com <mailto:deadalnix at gmail.com>>
>  >
>  > 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 <jmdavisProg at gmx.com
> <mailto:jmdavisProg at gmx.com>
>  >>> <mailto:jmdavisProg at gmx.com <mailto:jmdavisProg at gmx.com>>>
>  >>>
>  >>>    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