Function pointers/delegates default args were stealth removed?

[Steven Schveighoffer]

On Tue, 28 Aug 2012 04:57:53 -0400, Don Clugston <dac at nospam.com> wrote:

> On 27/08/12 16:16, Steven Schveighoffer wrote:
>> On Sun, 26 Aug 2012 18:26:40 -0400, Manu <turkeyman at gmail.com> wrote:
>>
>>> I just updated to 2.60 and found errors throughout my code where  
>>> function
>>> pointers default args no longer work.
>>> *Every single project* I've written in D, 5 projects, don't work  
>>> anymore,
>>> including my projects at work.
>>
>> OK, I've read all the posts on this, and this is what I think would
>> solve the problem:
>>
>> 1. default parameters are part of the function pointer type, because a
>> function pointer has a type.
>> 2. The mangled name of the function that is assigned to that function
>> pointer does *not* have default parameters mangled in.  Only the
>> function pointer type has them.
>> 3. Since the default parameters are part of the type, but not defined by
>> the function it points to, you can use interchangeably functions of the
>> same type which define default parameters or not (or define different
>> ones).  The default parameters follow the function pointer variable.
>
> This sounds like sloppy thinking.
> I _think_ what you are saying is that there should be implicit  
> conversions from one function pointer type, to any other that has the  
> same basic declaration, but different default arguments.
>
> But then you get problems with IFTI.
> void foo( void function(int x), double) {}
> void foo( void function(int x), int) {}
>
> void function(int x = 10) bar;
>
> foo(bar, 5); // fails -- ambiguous. Both overloads match with implicit  
> conversions.

First, I don't see IFTI anywhere in there.

Second, why is this a problem?  We already have oddities in terms of how  
implicitly converting one argument makes the interpretation of  
non-ambiguous arguments ambiguous.

I don't think it's sloppy, my logic is: we can already (I think) do this  
in library code, so why is it impossible for the compiler to figure out?

> But really, it seems to me that this whole feature is just syntax sugar  
> for one special case of currying.

Probably.  But it is what it is -- a poorly implemented/designed language  
feature.  In most cases, we don't simply drop them without giving a  
replacement.  Examples: octal literals, complex numbers, scope classes.

-Steve