Function pointers/delegates default args were stealth removed?

[Walter Bright]

On 8/26/2012 5:06 PM, Manu wrote:
> To be fair, it's not a very lively discussion. Spans 1 day, and only 3 people
> comment :)

If you want a lively discussion, start one up about what to name a keyword :-)


> Is that really an exhaustive set of options? It seems the other possibility
> (including the default arg in the equivalence test) wasn't really considered.
>
> The part that I don't understand is how the situation manifests in the first place:
>
>      auto foo = (int a = 1) { return a;};
>      auto bar = (int a) { return a;};
>
>      writeln(foo()); // writes '1'
>      writeln(bar()); // writes '1' also!
>
> These are 2 distinct assignments. I would expect foo and bar /would/ each take a
> type that is technically equivalent, but foo's type would have the bonus default
> arg in its type record, just as a function pointer that were declared explicitly.

That's the way it used to work. The problem is, what are those types? Are they 
the same types or not? You're saying sometimes they are the same type, sometimes 
they are not. It's a mess.

> At what point does the compiler become confused? They never interact... The
> expected behaviour seems obvious to me, foo and bar should effectively be:
>     int function(int a = 1) foo = ..;
>     int function(int a) bar = ...;

It seems obvious only in the trivial case. What if you passed foo to a function? 
Now what type is it? What is the mangling for the type?

> I presume if I typed that code, there would be no problem?
>
> The discussion is obviously regarding implementation details...?

No.

>
>
>     The trouble for function pointers, is that any default args would need to be
>     part of the type, not the declaration.
>
>
> I thought they were part of the type already? I would have thought that's where
> they should be. Why is their new home more 'proper'?

Because are the types the same or not?

>
>
>     I know it broke code (for many others, too), and I'm very sorry about that,
>     but I don't see another way out.
>
>
> It's a rather major breakage. I've seen you reject far more important changes
> solely on the grounds that they are a breaking change before...

Unfortunately, it was already broken, as the bug report showed. It's a matter of 
where the crack shows up.



>     (Many uses of default arguments can be replaced with overloaded functions.)
>
>
> Can you suggest how? I can't think of a feasible approach.

I'd have to see what you were trying to do.


> You can't overload function pointers (multiple instances of variables with the
> same name). And by definition of a function /pointer/, I don't own the target
> function to overload it.
> I can't reasonably produce static wrappers either, unless the wrapper receives
> the function pointer I intend to call as an arg, which is super nasty.
>
> I can probably address the global/static ones via wrappers, but I don't love
> redundant function calls, it reduces debug build performance (see: all my rants
> about __forceinline), but that would only address the problem in a few situations.
> This also undoes all that good work recently with the parameter list traits >_<
>
>
> As I see it, calling a function is possibly the single most important thing a
> programming language does. Flexibility in this regard is valuable. Default args
> in function pointers was a HUGE selling point of D to me, I've made extremely
> liberal use of this feature to great benefit throughout all my projects.
> But perhaps most importantly, this change has a huge impact on my code at
> work... I don't really want to imagine telling my boss that I need to rewrite
> the engine bindings and integration code. I'll look like the biggest dick this
> side of the Baltic :/

If you can show me a generic example of what you are trying to do, perhaps we 
can suggest a reasonable alternative.