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


It builds on the opening examples in:


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?



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.



Reply via email to