[Issue 23916] Non-eponymous template instances have a "type" (void)

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=23916

--- Comment #8 from Vladimir Panteleev <dlang-bugzilla at thecybershadow.net> ---
(In reply to Nick Treleaven from comment #7)
> Can you give examples of confusing code?

I find your examples above confusing.

It is meaningless for a template to have a type.

It is also meaningless for a template instance to have a type, unless of course
it is an eponymous template which resolves to something that has a type.

"void" is an arbitrary choice. Why the unit type? Why not the bottom type? Why
not typeof(null), etc.?

> First, you should acknowledge that the constraint is not meaningless as you
> said. The usefulness of that constraint is independent of this issue.
> 
> Next, the reader should understand constraints. They don't have to know that
> a template instance has void type, yet their code will magically work for
> people who do know that.

I have no idea what you're trying to say by this.

> > Wouldn't something more explicit be much better?
> 
> Such as what?

To check that something is a type: if (is(X))
To check that something is a template: if (__traits(isTemplate, X))
To check that something is a template instance: if (is(X : Template!Args, alias
Template, Args...)) (or use alias parameter destructuring)
To check that something is an instance of a particular template: if
(__traits(isSame, TemplateOf!X, SomeTemplate))

Yeah, these are also awkward and inconsistent. std.traits does have a bunch of
helpers, such as `isType`, and there've been proposals to put something more
readable on top of IsExpression in Phobos.

> You are asking for a change so the burden is on you to justify it. If you
> like, make a draft pull request and see if it breaks anything.

What is this, 90's newsgroups? I'm not playing this "burden of proof" BS.

There is nothing personal about this issue. We do not file requests that we are
personally "asking for"; we file proposals on how to progress on our shared
goal of making the language better. And bugs.

Every single bit of the language spec needs to be be defensible. If something
is not backed by a strong rationale, it is candidate for revision, and we do
need to continuously attack and revise the weak parts of the language.
Otherwise, we are never going to get a better language.

And yeah, fixing this will probably require a deprecation cycle.

--