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