DIP 1017--Add Bottom Type--Final Review

[H. S. Teoh]

On Fri, Jan 18, 2019 at 03:55:40AM +0000, Paul Backus via Digitalmars-d wrote:
> On Friday, 18 January 2019 at 01:31:47 UTC, H. S. Teoh wrote:
> > I don't argue that it's not a unit type.  But that's not the same
> > thing as saying it's *the* unit type.  There may be multiple,
> > distinct unit types, because D types are not structural types in the
> > type theoretic sense; for example:
> > 
> > 	struct A { int x; }
> > 
> > is a distinct type from:
> > 
> > 	struct B { int x; }
> > 
> > in spite of being identical product types according to type theory.
> 
> The official term for this is "nominal typing" [1]. In a
> nominally-typed language, it is perfectly normal for there to be many
> distinct types that are structurally identical. In fact, the entire
> *point* of a nominal type system is to allow the programmer to
> distinguish between types that are structurally identical.

Thank you. That's the gist of it.


[...]
> The downside of a nominal type system is, as you've noticed, that one
> cannot speak of "the" unit type, or indeed "the" type with any
> particular structure.
> 
> However, even if there are many possible unit types in D, that does
> not mean we cannot single one out for special treatment--indeed, we
> *do* single one out, already. `void`, in its role as a function return
> type, is different from all other (structurally-equivalent) unit types
> in that it is the only one that can be returned implicitly:
[...]
> Another way to think of it is that, in a nominally-typed language, it
> is not enough for "the" unit type (if such a thing is to exist) to
> have a canonical structure. It must also have a canonical *name*.
[...]

So now we're clearer about what exactly is involved here.  If we want to
"clean up" the "messy" meaning of `void`, we should first recognize that
it's an overloaded keyword with at least 3 or 4 different meanings:

1) A unit type -- in the context of a function return type.

2) A bottom type -- in the context of a variable declaration, which
makes said declaration illegal (though this latter point is not
mandatory and could possibly be altered as part of introducing an
explicit bottom type to D).

3) The top type -- when used in its pointer form as void*, where it
really means Any* where Any is the top type.

4) An uninitialized value -- when used in variable declarations of the
form `T x = void;`.

So in some sense, D already *has* a distinguished unit type, a bottom
type (of sorts), and even a top type. (For our purposes, (4) is not
really relevant.)  It's just that they are currently not treated as
first-class citizens, and therefore can only be used in certain,
constrained contexts, and cannot be freely combined with other types as
one might desire to.  Our "arithmetic system", so to speak, already has
the necessary concepts of 0, 1, and infinity, but they are just
inconsistently lumped together under a single name and consequently
arbitrarily restricted.

So the course of action seems quite obvious, at least at a high level:

a) Rename the various usages of `void` into distinct names reflecting
their actual meaning;

b) Remove the arbitrary restrictions on their usage.

We cannot do (b) before doing (a), because it will end up with a mess
where `void` means multiple things in the *same* context, which is
unworkable. (And besides, continuing to use `void` only prolongs the
conflation of incompatible concepts in users' minds, which will only
lead to misunderstanding and wrong usage -- i.e., bad UI design.)

Of course, there's a lot of details omitted in this simple plan of
action.  Before we can remove the restrictions on the unit / top /
bottom types, we better be clear exactly what kind of semantics we
expect when we combine them with other types in the existing system.
We have to worry about backward-compatibility, migration schedules, and
so on.  It will be a pretty big change, more than what the DIP in
question appears to be suggesting.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.