What to do about default function arguments

[bearophile]

Walter:
> A subtle but nasty problem - are default arguments part of the 
> type, or part of the declaration?

I'm waiting for years to see you finally facing this problem too 
:-) The current situation is not acceptable, so some change of 
the current situation is required, probably a small breaking 
change.

The simplest solution is to the breaking change of disallowing 
default arguments for function pointers and delegates. This also 
means disallowing talking the pointer/delegate of function with 
default arguments. The advantage of this solution is its 
simplicity, for both the compiler the D programmer and the D 
newbie that has to learn D.

A second alternative solution is to put the default arguments 
inside the function mangled and, and to avoid troubles, allow 
this only for POD data known at compile-time (and throw a 
compile-time error in all other cases). This has the advantage 
that common default arguments like "true", 15, 2.5, are accepted, 
so this gives some flexibility. One disadvantage is that you need 
to add a special case to D, but it's not a nasty special case, 
it's a clean thing.

A third possible way is to put the default arguments inside the 
delegate/function itself, as in Python. So default arguments for 
delegates/function have a different semantics. Then add a hidden 
extra field to such delegates/functions, a ubyte that tells the 
function how many arguments are actually given to the function 
(so the function is later able to use this argument to know how 
many arguments replace with the default ones). This has some 
disadvantages, because you can retrofit already compiled modules, 
so you can't get the function pointer of a function that doesn't 
have this hidden argument. The advantage is that the semantics is 
clean, and it's quite flexible.

Bye,
bearophile