quirks of functions and delegates

[Jarrett Billingsley]

"Ender KaShae" <astrothayne at gmail.com> wrote in message 
news:f8t0t1$1m93$1 at digitalmars.com...
>> template Templ(T : U function(V), U, V...)
>> {
>>     const Templ = T.stringof;
>> }
>>
>> void main()
>> {
>>     pragma(msg, Templ!(int function(float)));
>>     pragma(msg, Templ!(void function(char[], int[char[]])));
>> }
> for me this outputs "Error: string expected for message not Templ"

You must have an old compiler then.  This works fine with DMD 1.020 and 
should work in 2.003 by proxy.

> this is the code that I used (and failed):
> template Templ(T : U function(V), U, V...)
> {
>    T f;
>    U call(V v) { return f(v);}
> }

I think you may have found a bug here.  For some reason, T is correct, U is 
correct, but V ends up as an empty tuple every time.  Odd.

> int Foo() {return 1;}
>
> void main() {
> writefln(typeid(typeof(Foo)));
> }
>
> prints int()

I see what you're saying now, and it's actually not ambiguous.  See, the 
"function call without parens" only comes into effect when symbol lookup 
finds that the symbol is a function type, but the destination is a different 
type.  Then it implicitly inserts the parens and tries to do semantic 
analysis on it again.  However, inside typeof(), there's no ambiguity; 
typeof(Foo) just means "the type of the symbol Foo".  However, if you do 
something like "writefln(typeid(typeof(Foo + 1)))" _now_ the implicit 
function call kicks in, and you get "int".

> writefln(typeof(Foo));
>
> gives "Error: type int() is not an expression"

Makes sense, you can't use a type as an expression.

> writefln(typeid(Foo));
>
> gives the error: "function main.Foo is used as a type"

Again makes sense, as Foo refers to a function, and not a type.