alias parameters and basic types

[Jonathan M Davis via Digitalmars-d]

On Saturday, July 30, 2016 19:41:27 Lodovico Giaretta via Digitalmars-d wrote:
> 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

Then maybe it'll change. I just know what was in the bug reports that you
were listing. You seemed to be asking why the behavior was the way it was
and then proceeded to ignore the links that you gave that explained exactly
why.

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

That's because aliases don't really exist. When an alias is declared, every
instance of its used is effectively replaced textually. The compiler doesn't
care about the alias beyond translating it into what it's aliased to. So, if
you have

alias Int = int;

and you use Int somewhere, it's semantically identical to using int. You
don't actually get a symbol called Int out of the deal. You just get to call
int Int.

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

I confess that I've always thought that it's messy to have a template accept
both types and objects, but there are folks who like to do that. But since I
never do, I never hit any cases where it would matter.

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

The one that needs to be convinced is Walter. Personally, I really don't
care. I don't really see any value in it, but I'm not against it. I was just
telling you what Walter had said, since you seemed to be posting links
without reading them. But if David did indeed convince Walter (as the link
above implies), then presumably it'll change at some point. It wouldn't
surprise me though if Walter has forgotten about it if it hasn't happened by
now.

- Jonathan M Davis