The bizarre world of typeof()

[Lars T. Kyllingstad]

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