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