https://d.puremagic.com/issues/show_bug.cgi?id=5710
--- Comment #29 from Kenji Hara <[email protected]> 2013-11-18 02:00:56 PST --- (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. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
