The bizarre world of typeof()

[Lars T. Kyllingstad]

Don wrote:
> I'm trying to make sense of the rules for 'typeof'. It's difficult 
> because DMD's behaviour is so different to the spec. Here's four simple 
> cases.
> 
> // This doesn't compile on D1.
> //alias typeof(int*int) Alias1;
> 
> // This compiles in D1, but not in D2.
> alias int Int;
> alias typeof(Int*Int) Alias2;
> 
> // Yet this DOES compile on D2 !
> typeof(T*U) foo(T, U)(T x, U y) { return x*y; }
> alias typeof(foo(Int, Int)) Alias3;
> 
> // And this fails on both D1 and D2, with a dreadful error message.
> //alias typeof(foo(int)) Alias4;
> 
> I can't see anything in the spec to say why ANY of these examples should 
> compile. Yet, the existing template constraints features relies on the 
> Alias3 case.


Here are a few more:

     class Foo { real bar() { return 1.0; } }
     Foo foo = new Foo;

     // Passes, but should fail.
     static assert (is (typeof(foo.bar) == function));

     // Passes, as expected.
     static assert (is (typeof(&foo.bar) == delegate));

     // Passes, but should fail. This is similar to Don's examples.
     static assert (is (typeof(Foo.bar) == function));

     // This one fails with the following hilarious message:
     // Error: static assert  (is(real function() == function)) is false
     static assert (is (typeof(&Foo.bar) == function));

I have no idea why typeof(&Foo.bar) even works, but it does. &Foo is 
completely meaningless.


> I can see two ways forward:
> (1) enforce the existing spec. Make all uses of types as expressions 
> into a bug. This will break a lot of existing code, including several in 
> the DMD test suite!
> You'd generally need to include a .init whenever using a type inside a 
> typeof(). This would make some code a lot uglier.
> I'm also not sure what happens with alias parameters. (If A is an alias 
> to a type, then typeof(A*A) should be changed to typeof(A.init*A.init); 
> but if it's an alias to a variable, it should remain as typeof(A*A)).
> 
> (2) Define that, inside a typeof() expression, any type T is translated 
> into T.init. The syntax for typeof() would need to be changed, in order 
> to allow the case 'alias1'.
> 
> Note, however, that in both cases there's no such thing as .init for 
> tuples; it might need to be added.
> 
> Behaviour (2) is probably more convenient, behaviour (1) is easier to 
> justify. But I think the existing behaviour of typeof() doesn't make 
> much sense.


I vote for (1). There should be as few "special cases" in the language 
as possible.

-Lars