DIP 1011--extern(delegate)--Preliminary Review Round 1
soolaïman
sahmi.soulaimane at gmail.com
Sat Jul 21 17:54:17 UTC 2018
I know this one year old already but the DIP is still in formal
review.
I Think the inability to create a delegate with a custom object
as its context similar to delegates created from member functions
should be fixed in a library solution rather than making a
language change. A simple implementation that you could try:
```
import std.traits;
@system ReturnType!F delegate(Parameters!F[1..$])
makeExternDelegate(F)(F fp, void* this_) {
struct Delegate { void* ctxptr; F fptr; }
auto dlg = Delegate(this_, fp);
auto _tmp = cast(void*) &dlg;
auto dlgp = cast(typeof(return)*) _tmp;
return *dlgp;
}
unittest
{
struct O { int val; }
auto objp = new O(1);
static int getVal(O* this_) {return this_.val;}
auto dlg = makeExternDelegate(&getVal, objp);
dlg();
assert(dlg() == 1);
objp.val = 1123;
assert(dlg() != 1);
assert(dlg() == 1123);
}
```
However I think the compiler should still disambiguate the output
of the addressof (&) operator between free and member functions,
I find the difference to be rather an implementation detail that
a user should not have to worry about. I also find this DIP to be
like an awkward deprecation process for such disambiguation.
Perhaps this should rather be on the list of breaking changes of
D3. D3 would be where the language would grow up from past
mistakes, even if that should break compatibility with C! I know,
no body cares about that.
More information about the Digitalmars-d
mailing list