Function pointers/delegates default args were stealth removed?

Timon Gehr timon.gehr at gmx.ch
Mon Aug 27 02:19:45 PDT 2012


On 08/27/2012 05:05 AM, Walter Bright wrote:
> On 8/26/2012 6:55 PM, Timon Gehr wrote:
>> On 08/27/2012 02:44 AM, Walter Bright wrote:
>>> On 8/26/2012 4:50 PM, Timon Gehr wrote:
>>>> On 08/27/2012 12:41 AM, Walter Bright wrote:
>>>>>
>>>>> The trouble for function pointers, is that any default args would need
>>>>> to be part of the type, not the declaration.
>>>>>
>>>>
>>>> They could be made part of the variable declaration.
>>>
>>> You mean part of the function pointer variable?
>>>
>>
>> Yes.
>>
>>> Consider what you do with a function pointer - you pass it to someone
>>> else. That someone else gets it as a type, not a declaration.
>>
>> If it is a template function, yes. But then you may as well pass the
>> function pointer variable per alias, which is common.
>
> You pass the function declaration by alias, not the function pointer
> declaration. In which case you will get the default arguments.
>

The function declaration is not necessarily available and the
pointer/delegate might not be a constant. This is the point of function
pointers and delegates.

>>
>> Otherwise someone else gets nothing but a parameter declaration.
>>
>>> I.e. you lose the default argument information, since that is not
>>> attached to the
>>> type.
>>>
>>
>> I think most valid existing use cases would still be supported:
>>
>> int execFunctionPointer(int function(int = 2) fun){
>>      return fun();
>> }
>>
>> auto dg = (int x, int y=2){ return x+y; }
>> writeln(range.map!dg());
>>
>> int function(int=3)[] funs;
>> funs[0]();
>>
>> It is up to you if it is worth the effort, of course.
>
> and it falls apart immediately once you try to transfer that function
> pointer anywhere.
>

No it does not. The examples people have posted where it breaks their
code that I am aware of all would work with this scheme.

What possible use case do you think would have to be supported by
function pointer/delegate default arguments that cannot be supported
without serious implementation problems?



More information about the Digitalmars-d mailing list