On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
An issue is that we already have typeof(null). typeof(null)
and typeof(assert(0))* are two ways to specify almost the same
thing. One question is whether typeof(assert(0))* and
typeof(null) should be the same, or if the former should not
implicitly convert to class references.
I have also argued in the past that there should be a separate
typeof([]). This role would now be filled by
typeof(assert(0))[]. However, changing the type of '[]' may
break code.
You're on to something here. Perhaps we go the inverse route
and define the bottom type as typeof(*null). Would that
simplify matters? There is some good consistency about it:
null: a pointer to anything. But can't be dereferenced.
*null: well, therefore... anything. But can't be created.
The latter is a mere consequence of the former.
I'd really prefer if you avoided the whole `typeof(assert(0))`
thing.
First off, it's way too verbose for a simple concept. In general,
code is much more readable when you can read functions as `Type
functionName(args)`, rather than template-style
`expr(valueof!(thing + otherThing).typeof) functionName(args)`,
so I think it would be better not to encourage adding more
expressions as return types.
I think the following:
noreturn_t logThenQuit(string message)
is much more readable and obvious (especially to a beginner) than:
typeof(*null) logThenQuit(string message)
Of course, you could implement typeof(*null); and also add
noreturn_t as an alias; it might be a good compromise; I'd still
dislike it because it encourages people to use the verbose hard
to understand version.
The second reason I don't like it is that I feel it's just trying
to be clever for the sake of cleverness. I don't think we need a
language feature that perfectly matches the idea of not returning
from a function on a deep, philosophical level; we just need a
way to tell the type system "Hey, this function doesn't return!".
I don't think `typeof(*null)`, or `typeof(assert(0))` brings any
advantage in term of real life user code, and I don't think it's
worth the confused users that would look at code and go "Uh? What
is the type of *null?" or "I thought assert was void! What would
you get the type of assert()?".
