alias parameters and basic types

[Lodovico Giaretta via Digitalmars-d]

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/lnaidcyffgqkvekawsmq@forum.dlang.org

> 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.