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
