DIP 1017--Add Bottom Type--Final Review

[Johannes Loher]

On Wednesday, 16 January 2019 at 09:43:24 UTC, Dukc wrote:
> On Wednesday, 16 January 2019 at 08:47:48 UTC, Johannes Loher 
> wrote:
>> On Tuesday, 15 January 2019 at 18:51:13 UTC, Johannes Loher ```
>> alias void = Tbottom*;
>> ```
>
> I believe you meant `enum null = typeof(Tbottom*).init;`

No, I actually meant it exactly as I wrote it. The reasoning is 
the following: If we were to make `void` a proper unit type, it 
needs to be a type with exactly one value. We could choose any 
type we want for this, as long as it only has one value. E.g. 
`struct A {}` could be a candidate for such a type as any two 
instances of it are equal. However, `Tbottom*` is also a type 
with only one value: `null`. To me it seemed like the canonical 
choice for defining `void`.

There might actually be reasons not to do this. As I mentioned, 
Kotlin is going another route. `Unit` and `Nothing?` are 
different types in Kotlin, although they both can hold exactly 
one value: `Nothing?` can only hold `null` and `Unit` only has 
the value `Unit`. I don't think their decision to separate those 
types is arbitrary. In particular, `Nothing?` is a subtype of all 
optional types in Kotlin. Maybe there are some bad implications 
of making the unit type a subtype of all optional types, I don't 
know. The analogue in D (if `void` is defined to be `Tbottom*` 
would be that `void` is a subtype of all pointer types, which 
might seem weird.

What you are describing is actually completely orthogonal to what 
I suggested. Even if `void` is defined in some other way and even 
if we keep it like it is (instead of making it a proper unit 
type), we can still define `null` to be the only value of 
`Tbottom*`. Now that you suggested it, it also really makes sense 
to do this in my opinion. (It would allow us to get rid of `null` 
as a builtin symbol)