https://issues.dlang.org/show_bug.cgi?id=17080
--- Comment #10 from Sprink <[email protected]> --- (In reply to Dicebot from comment #9) > Because I disagree with your proposed fix and overall judgement of the > problem but don't want to argue about it in context of this issue. In what context then? After a fix for this is pushed out the door without even discussing alternative solutions to the problem because the test code in an issue was a tad bit different? These issues are directly related, pushing one fix out the door without even discussing alternatives is just nonsense. > It is more intrusive change (will fail in more context) and I think that > getting address of a method as a delegate is perfectly legitimate code - it > would allow to set `dg.ptr` manually later to call it with arbitrary context. Which wouldn't be allowed in @safe code and would be more error prone cause dg.ptr is of type void*. When a very specific type is needed for the delegate to work properly. Adding a member-to-function pointer type would allow for it to be used in @safe code, would be less error prone as you can work with the type system to ensure you pass the correct type, rather than void* for "dg.ptr". It'll also allow D to better interface with C++, related to issue 16527. What exactly don't you agree with here? With your fix issue 3720 is still a problem with a "dg.ptr" set to null, doesn't work in @safe code and you can convert any pointer type to void* for "dg.ptr". --
