2013/2/27 deadalnix <[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]>> >>> >>> 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. 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. Kenji Hara
