DIP 1011 library alternative

[Andrei Alexandrescu]

On 05/15/2018 08:44 PM, Jonathan Marler wrote:
> On Tuesday, 15 May 2018 at 21:25:05 UTC, Andrei Alexandrescu wrote:
>> Hello, I was reviewing again DIP 1011 and investigated a library 
>> solution. That led to
>>
>> https://gist.github.com/run-dlang/18845c9df3d73e45c945feaccfebfcdc
>>
>> It builds on the opening examples in:
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md
>>
>> I'm displeased at two aspects of the implementation:
>>
>> * Perfect forwarding is tedious to implement: note that makeDelegate 
>> hardcodes void as the return type and (int, float) as parameter types. 
>> Ideally it should accept any parameters that the alias passes.
>>
>> * Pass-by-alias and overloading interact poorly. Does anyone know how 
>> to refer by alias to one specific overload?
>>
>>
>> Thanks,
>>
>> Andrei
> 
> Now that I've had a chance to look the example you've shared, the only 
> comment I'd make is that DIP1011 aims to allow applications to create 
> "delegate-compatible" functions that don't require generating a wrapper 
> function to forward a delegate call to the function at runtime  In this 
> example, 2 functions have been defined that take a class and a struct 
> pointer as the first argument, however, these function are not ABI 
> compatible with the delegate ABI meaning you will have to generate a 
> runtime "conversion" function to forward a delegate call to call the 
> function.

Affirmative. The important matter here is the number of indirect calls, 
which is not increased; forwarding direct calls are often easy to inline 
and even if not are cheap (subject to the number and size of their 
arguments).

> extern(delegate) allows the application to generate the function using 
> the delegate ABI in the first place so no "conversion" is necessary. To 
> achieve this with a libary solution, you need to modify the function 
> definition itself, not just create a wrapper around it.

Affirmative. But that's just stating it. The question is how needed and 
useful that is.

At the least, this feedback prompts for changes the rationale and 
motivation of the DIP. The bulk of the current rationale rests on use 
cases and the disadvantages of inferior workarounds. (The consistency 
with UFCS rewrites argument is weaker but valid, and stays.) The DIP's 
rationale would need to be redone to compare the proposed feature with 
the best known library solution (derived from the proof of concept in 
this thread), and them build an argument that it is needed based on (a) 
remaining disadvantages of the library solution and (b) convenience for 
frequent/intensive use.

We're not rejecting the DIP outright but we point out that it needs 
rework in wake of this new evidence of competing alternatives. Feel free 
to reach out privately for further discussion.


Thanks,

Andrei