DIP27 available for destruction

[deadalnix]

On Tuesday, 26 February 2013 at 20:00:26 UTC, Jonathan M Davis 
wrote:
> Wouldn't this fall apart completely with auto or IFTI (implicit 
> funtion
> template instantiation)? For instance take
>
> auto foo(T)(T blah) {...}
>
> int func() { return 7; }
>
> void bar()
> {
>  ...
>  foo(func); //Does this call func or pass its address?
>  auto f = func; //Does this call func or take its address?
>  ...
> }
>

Both are the function. None is listed in the implicit call cases. 
Are you sure we are talking about the same DIP ?

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

That is not how C works. In C, the function name represent the 
actual instruction f the function (and this is why taking the 
address of the function gives you a function pointer). This 
mechanics is reproduced in D but has no real use case (even if it 
is around for more than 40 years) and add complexity.

The DIP proposes something close to what exists in C# and 
Javascript.

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

Considering that both statement above are wrong, I think you 
should reconsider that conclusion.