[Bug 191] New: Cannot refer to member variable in default value for method parameter

[BCS]

Bruno Medeiros wrote:
> Don Clugston wrote:
> 
>> Bruno Medeiros wrote:
>>
>>
>> I'm almost certain that default values should work that way. They 
>> should just be syntactic sugar for overloaded functions.
>> Right now, they have the same problem which C++ has -- there's no way 
>> that a template can find out what the default values are, and the 
>> default values can't be used by function pointers or delegates.
>> So for example,
>>
>> void foo(int a, int b=2, int c=3) {}
>>
>> void goo(int a, int b, int c) { }
>> void goo(int a, int b) { goo(a, b, 3); }
>> void goo(int a) { goo(a, 2, 3); }
>>
>> void function(int) boo;
>>
>> foo(7); // ok
>> goo(7); // ok
>>
>> boo = goo; // ok
>> boo(5);
>>
>> boo = foo; // doesn't compile -- why not?
>> boo(5);
>>
>>
> 
> You meant:
>   boo = &goo; // ok
>   boo(5);
> 
>   boo = &foo; // doesn't compile -- why not?
> 
> 
> Anyway, "Why not?" ? How could that compile? Even with that syntatic 
> sugar the problem would subsist: remember that the expression (&foo) has 
> to be evaluable by itself, and if there are many overloads of foo there 
> is no way (with that syntax at least) to choose the correct one. (DMD 
> currently chooses the lexically first overload)
> 
> 

Things get worse when auto is used. you end up with a type that is 
indeterminable without knowing the lexical order of function 
decelerations. I that case code validity is dependent on the order of 
other code.


int foo(long i, int j){return i+j;}
char[] foo(int i){return i;}


auto fp = &foo;

auto i = foo(0,0);	// legal unless foo's are reversed

What is need is a way to specify a particular function as a pointer.

auto fp1 = &foo(int);
auto fp2 = &foo(long,int);	// function don't run
assert(fp1 != fp2);