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

[Don Clugston]

Bruno Medeiros wrote:
> Don Clugston wrote:
>> Bruno Medeiros wrote:
>>> BCS wrote:
>>>> Deewiant wrote:
>>>>> All I can find about default parameters in the spec is at the 
>>>>> "Functions" page,
>>>>> where they pop out of the blue in the phrase "A function 
>>>>> parameter's default
>>>>> value is not inherited", which is all that's said about them. The 
>> ....
>>>>
>>> Hum, quite a catch you got there! Not only should it be better 
>>> documented, but maybe it shouldn't work this way.
>>> Perhaps the default values should be set not at the call site, but by 
>>> the function itself (thus depending on it's run-time type, and not 
>>> it's compile-time type),
>>
>> 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)

But the 'goo' example does compile. Why is there a difference between 
'goo' and 'foo'?
AFAIK, default parameters were introduced (in C++) purely as syntactic 
sugar, and AFAIK they are only ever used in that way. I think they 
should be just syntactic sugar. As they exist in both D and C++, they 
are a quirky language primitive which cannot be emulated in any other 
way. They lead to some horrible corner cases.