The bizarre world of typeof()

[grauzone]

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.

We also need typeof(&Foo.bar) to get the parameter and return types for 
the bar method.

> -Lars