Partial argument specification

[downs]

Lars Kyllingstad wrote:
> downs wrote:
>> Lars Kyllingstad wrote:
>>> Hello,
>>>
>>> There is a feature I would very much like to see in D. I don't know if
>>> it has been discussed before, or whether is's even possible, but I'm
>>> just going to throw it out here. Please tell me what you think.
>>>
>>> Suppose you have a function that takes a certain number of arguments,
>>> say
>>>
>>>   creal f(real x, int i);
>>>
>>> Then it would be neat if one could specify just some of the arguments,
>>> and have the result be a pointer to a function that takes the remaining
>>> arguments. To clarify, the type of
>>>
>>>   f(real, 2)
>>>
>>> would then be
>>>
>>>   creal function(real)
>>>
>>> Why would this be nice? As an example, say you have a function that
>>> calculates the derivative of another function at a certain point:
>>>
>>>   real derivative(real function(real), real z);
>>>
>>> With the above notation I can use this for functions of several
>>> variables:
>>>
>>>   real f(real x, real y) { ... };
>>>   auto dfdx = derivative( f(real, 1.23), 4.56 );
>>>
>>> As an added bonus, I can even differentiate with respect to y:
>>>
>>>   auto dfdy = derivative( f(1.23, real), 4.56 );
>>>
>>> Already, there are several ways to do similar things, but in my opinion
>>> they are not as good:
>>>
>>> 1. Use templates
>>> Nice, but only works when the pre-specified arguments are known at
>>> compile time. (Or is there some trick I don't know about?)
>>>
>>> 2. Use functors
>>> This works, but leads to worse performance and is in my opinion less
>>> elegant. One has to type a lot of code just to define simple functions.
>>>
>>> 3. Use wrapper functions
>>> Same problems as (2), and also leads to use of global variables.
>>>
>>> 4. The GSL way: Pass remaining arguments in a void* pointer.
>>> Example:
>>>
>>>   real derivative(real function(real, void*), real z);
>>>
>>> IMO, this is UGLY, not to mention un-D-ish.
>>>
>>>
>>> I mainly use D for numerical computations, hence the examples above. But
>>> I'm sure there are many other uses for such a feature. What do you
>>> think?
>>>
>>> -Lars
>>
>> How about an implicit functor?
>>
>> creal f(real x, int i);
>>
>> auto f2 = bind(&f, _0, 2); // I think
>>
>> auto f2 = &f /rfix/ 2; // tools version
>>
>> This creates a functor on the heap, and is indeed slower, but it's
>> more elegant than you make it sound :)
> 
> Ok, but say I want to do this several times:
> 
>   for (real y=yStart; y<=yEnd; y+=yStep)
>       derivative(&f /rfix/ y, 1.23);
> 
> Would it be any faster if your /rfix/ (or a similar function) created
> the functor on the stack instead?
> 
> -Lars

Yes, but how could it possibly do that?

After all, then the data would become invalid on scope exit, which is exactly what we're trying to avoid!