On Saturday, 30 July 2016 at 19:21:27 UTC, Jonathan M Davis wrote:
I think that Walter's answer in those bug reports is pretty
clear.
Thank you for your answer.
I asked because I also found this[1], so I hoped it was going to
change.
[1]
http://forum.dlang.org/post/[email protected]
An alias parameter aliases a symbol. Basic types are keywords,
not symbols, so they can't be passed as an argument to an alias
parameter.
If I define `alias Int = int`, then `Int` is a symbol, not a
keyword. Yet it does not work, so the alias template does not
prohibit keywords, it prohibits basic types, even when named
without using a keyword.
And I confess that I don't know why you'd even want to. If
you're looking to pass a type, then just don't use an alias
parameter. A normal template parameter will do just fine. The
only reason that I see that makes the current behavior a bit
odd is the fact that other kinds of aliases do work with types.
So, it's arguably inconsistent to not have alias parameters
accept types, but given what alias parameters are intended for
and that they're completely unnecessary for passing types, I
don't really see a problem with the current behavior.
I agree it is not a critical feature. Its main value, IMHO, is
ortogonality and the principle of least-astonishment.
My current use case is a template that (for convenience) accepts
both types or variables, and in the case of variables applies
`typeof` to get the type. It's only sugar, as I could require the
user to apply `typeof` and only accept types in the template.
With the current rules, I have to write two templates, one with
alias that forwards to the other after applying `typeof`, while
if alias could also accept every type, I would write just one
template and use `static if` inside it.
In any case, glancing through those bugs, it's quite clear that
the behavior is intentional what the reasoning is.
It is indeed intentional, I just don't see what this restriction
buys. If it buys nothing (as I think it does), in terms of both
compiler complexity and language complexity, it should go for the
sake of consistency and ease of use (it's one less exception to
remember).
But I don't want to start a war over this, so please don't take
this as an attack. It's just some considerations.
