grauzone wrote:
Lars T. Kyllingstad wrote:
Kagamin wrote:
Lars T. Kyllingstad Wrote:
// This one fails with the following hilarious message:
// Error: static assert (is(real function() == function)) is
false
static assert (is (typeof(&Foo.bar) == function));
Failure is valid, compiler just can't show member function types
correctly.
I'm not saying it should compile, I'm saying that the compiler should
give an error when it encounters the expression &Foo.bar, and not just
because of the failed assertion. It's bad enough that it accepts
Foo.bar (this is what Don was talking about), but allowing one to take
the address as well is just nonsense -- even when it's in an
is(typeof()) expression.
In fact, &Foo.bar actually returns an address. The following compiles:
class Foo { real bar() { return 1.0; } }
auto f = &Foo.bar;
auto x = f();
Of course, when run, it segfaults on the last line. I wonder where f
actually points to.
We need that to get the address of a function. It's just that the type
of the returned object is a bit bogus: it's not really a function; it's
a method pointer casted to a function pointer. It simply has the wrong
calling convention.
Ok, thanks for explaining. Are there cases where it's useful to have a
pointer to a member function without its context?
We also need typeof(&Foo.bar) to get the parameter and return types for
the bar method.
Good point.
-Lars
