https://issues.dlang.org/show_bug.cgi?id=5710
--- Comment #35 from Martin Nowak <[email protected]> --- (In reply to Kenji Hara from comment #29) > (In reply to comment #27) > > (In reply to comment #26) > > > (In reply to comment #25) > > > > Good to see, that you already know this solution. > > > > I think the biggest hurdle to implement is teaching the IR/backend to > > > > get > > > > doStuff's this pointer from an array. > > > > > > Unfortunately it is merely an idea, and it would break existing delegate > > > ABI. > > > > How would it break the existing delegate ABI? > > Sorry, it was not good words. It will break some existing assumptions around > delegate. For example: > > class C { > void foo() {} > void bar(alias fun)() {} > } > void test() > { > C c = new C(); > auto dg1 = &c.foo; > > /* currently upsupported case. > > void nested() {} > auto dg2 = &c.bar!nested; > dg2(); > > #1. dg2.ptr cannot become c. > Instead, it should point to the "context pointer list". > But, if dg2 is returned from the function 'test', the list > should be allocated on heap. > */ > } > > #1 is necessary for the multiple-context delegates. But applying same rule > for existing one-context delegates will add hidden runtime cost against > existing code. > > To avoid the cost, we should introduce the second delegate type for the > multiple-context delegates. Then, the typeof(dg1) and typeof(dg2) will > become incompatible. It will make D's type system more complicated. > > Therefore, I had withdrawn my idea. It won't add enough benefits compared > with the necessary complexity. The type will be 'delegate void()' for both cases. True, 'dg1.ptr is c' and 'dg2.ptr !is c', but that doesn't affect the type as we don't inherit C++'s member pointer complexity. The function 'void bar(alias fun)()' can access the this pointer through 'dg2.ptr'. --
