Function pointers/delegates default args were stealth removed?

Carl Sturtivant sturtivant at gmail.com
Tue Aug 28 10:22:40 PDT 2012


On Monday, 27 August 2012 at 12:14:30 UTC, Manu wrote:
> On 27 August 2012 14:08, Carl Sturtivant <sturtivant at gmail.com> 
> wrote:
>
>>
>>> extern(C) void function( ref const(Vector2) v0, ref 
>>> const(Vector2) v1,
>>> ref const(Vector2) v2, ref const(Color) color = Color.white, 
>>> BlendMode
>>> blendMode = BlendMode.Disabled ) fillTriangle2D;
>>>
>>
>> If function pointers could be called with fewer than the 
>> prototypical
>> number of arguments, and the remaining arguments be always 
>> initialized to
>> their .init defaults, you could perhaps make this sort of 
>> thing work
>> without the default argument values by using struct defaults.
>>
>> How would that be deficient?
>>
>
> ... no.
> Color does not .init == Color.white. You're suggesting I define 
> a new type,
> obscuring the API, every time I want a non-.init default arg?
> Also, I think it's correct that functions shouldn't be callable 
> without
> explicit parameters. Default args are carefully selected, and 
> they are
> always opt-in.
> 'v2' in this case shouldn't be allowed to default to [ NaN, NaN 
> ] if I omit
> it.

More specifically, you can get the default initialization of e.g. 
double to be different as follows.

import std.stdio;

struct dbl(double init) {
     double d = init;
     alias d this;
}

void main() {
	dbl!3.142 x;
	dbl!2.0 y;
	writeln(x*y);
}

In the case of an external(C) struct, the D definition can fix up 
its own default initialization without a new type name even. 
Color for example could be fixed up to initialize to Color.white 
by default.

And, having the compiler fix up omitted trailing arguments with 
.init default values could be confined to "opt-in" parameters by 
a small change to the type system for function pointers as 
follows.

The type of a function pointer could now include the number of 
trailing parameters that may be defaulted. This does not explode 
the size of a mangled name much. A syntactic mechanism to 
indicate which trailing parameters may be defaulted in a function 
prototype could be added to D. The default would be none with 
functions declared without that mechanism. This mechanism needs 
to be a part of the prototype so that it can be used on 
external(C) functions etcetera.

Now only trailing parameters that you intend to be defaulted 
would would get defaulted with the .init treatment. Others would 
be compilation errors.

Now what's wrong with this if there are no trailing argument 
defaults except for the .init defaults?



More information about the Digitalmars-d mailing list