First life-signs of type functions

[Stefan Koch]

On Tuesday, 12 May 2020 at 01:44:45 UTC, Steven Schveighoffer 
wrote:
> On 5/11/20 5:58 PM, Stefan Koch wrote:
>> 
>> In a type function alias cannot bind to values at all.
>> It can only bind to symbols or types.
>
> This seems like a problematic limitation. Aliases can bind to 
> values when they are part of a tuple. This means that type 
> functions are going to have to do weird template acrobatics to 
> deal with mixed tuples.
>
> For a long time, alias parameters wouldn't bind to int because 
> it was a keyword, not a symbol, even though you could alias int 
> as a declaration. It wouldn't even bind them to aliases of int 
> (even though they are not keywords). That has since been fixed, 
> and everything works great. I think we should avoid arbitrary 
> limitations like this, even if it's harder to get it to work.
>
> -Steve

The reason that happened is not so much a parser issue.
But it's because Basic Types are not Symbols.
Which is indeed a more or less arbitrary limitation.

Let's go through the reasoning for type functions now.
let's assume alias A would bind to a value, the string foo
for example.

string F(alias A)
{
     pragma(msg, typeof(A).stringof); // prints alias
     pragma(__traits(identifier, A); // error a string has no 
identifer.
     pragma(msg, is(A == string)); // prints false, because A does 
not hold the type string
     pragma(msg, A) prints "foo";
     pragma(msg, A == "foo") // error can't compare alias and 
string
     pragma(msg, is(A, "foo") // doesn't parse. The string "foo" 
is not a valid identifier
     return A; // error alias does not implicitly convert to 
string.
}

You see there would not be a point in allowing that.