Bottom Type--Type Theory

[H. S. Teoh]

On Thu, Jan 17, 2019 at 02:39:18AM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jan 17, 2019 at 02:59:09AM +0000, Meta via Digitalmars-d wrote:
> [...]
> > As an aside, the empty enum:
> > 
> > enum Empty
> > {
> > }
> > 
> > Is an uninhabited type similar to Bottom, but is not implicitly
> > convertible to any other type, unlike Bottom.
> 
> Unfortunately, you get a compile error for this declaration.
> 
> But assuming it were allowed, then it would be possible to declare
> multiple distinct empty enums that do not interconvert with each other,
> which would mean that there is not one, but arbitrarily many bottom
> types of this kind.

Further thoughts on empty enums in D: according to the spec, an enum
always has an underlying base type, the default of which is int.  So an
empty enum as declared above, if we were to hypothetically allow it,
would be a subtype of int (a bottom int subtype).  Which also means we
can declare:

	enum BottomStr : string { }

which, AFAIK, would be treated as something distinct from the bottom int
type.  So it would represent a different bottom type.

You'd need a "true" bottom type to get the direct equivalent of the
Bottom of type theory.

Of course, we could stipulate that all empty enums are interpreted as
Tbottom, which would clear up this mess -- but this is yet another area
where the DIP in question failed to address.


> > The empty struct:
> > 
> > struct Unit
> > {
> > }
> > 
> > Unit u;
> > writeln(u); // Prints Unit()
> 
> Oddly enough, Unit.sizeof == 1, as a hack for generating distinct
> addresses when you declare multiple instances of Unit. One would have
> expected .sizeof == 0 for a unit type (and NaN or an error if you
> attempted to take .sizeof of an empty enum, if empty enums were
> allowed).
[...]

And furthermore, as somebody has already pointed out, Unit as declared
above would be distinct from empty structs of any other name that you
might declare.  So there'd be multiple incompatible unit types. Which
again is a mess, since two functions that don't return values
("procedures") could ostensibly return distinct unit types (let's say
one returns void and the other returns Unit, or one returns Unit and the
other returns another empty struct of a different name), and you'd have
a messy incompatibility situation.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.