https://issues.dlang.org/show_bug.cgi?id=20687
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Steven Schveighoffer <[email protected]> --- It's very clear to me it should be available at compile time and runtime. Whether it is callable on its own is a matter for debate, but that would be a breaking change. If we made it unavailable at runtime, it is still available with &instance.fun.funcptr. What does funcptr return? If we started disallowing funcptr manipulation, then maybe this becomes invalid, but that is a whole new ball of code breakage that I don't think we want to get into right now. Even if we disallowed creating a variable that accepts such a member-function pointer, a delegate has no type information for it's context pointer, so something like this would still be possible: struct S { int x; void foo() {++x;} } struct T { int *x; void bar() {*x = 5;} } auto s = S(100000); T t; auto dg = &s.foo; dg.funcptr = (&t.bar).funcptr; dg(); // uses s.x as if it were a pointer If we wanted to talk about type safety in this area, the status quo does not cut it. While not type-safe, at least it can be made consistent. --
