First life-signs of type functions

Johannes Loher johannes.loher at fg4f.de
Tue May 12 17:26:20 UTC 2020


On Tuesday, 12 May 2020 at 14:14:21 UTC, Stefan Koch wrote:
> On Tuesday, 12 May 2020 at 11:39:04 UTC, Johannes Loher wrote:
>
>> Honestly, to me this sounds like a total mess. If templates 
>> allow binding alias to a value, so should type functions, or 
>> they should use a different name than "alias". Otherwise it's 
>> just confusing. To me it looks like for type functions, you 
>> think of "alias" as something like the "type of types". But 
>> for alias template parameters and alias declarations it is 
>> something completely different (as Steven  explained, it is an 
>> unrestricted compile-time name). For example, consider the 
>> following: [ ... ]
>
> are you sure that that is the case for alias declarations?
> For me
> alias a = "Foo";
> causes Error: basic type expected, not "Foo"
> Which is identical to how they behave in type functions;

You are right, the language is already inconsistent in that 
regard. However, the following works:

void main()
{
     static immutable x = 0;
     alias other_x = x;
     static assert(other_x == 0);
}

So type functions should support at least that much (I don't know 
if they do in what you have in mind right now):

auto typeFun(alias x)
{
     return x == "foo";
}

void main()
{
     static immutable x = "foo"
     static assert(typeFun(x));
}

Let's not create a third meaning for "alias"... Rather we should 
unify the 2 meanings that exist right now.


More information about the Digitalmars-d mailing list