Bottom Type--Type Theory

[Simen Kjærås]

On Thursday, 17 January 2019 at 10:35:00 UTC, Dukc wrote:
> I think `void` can still be saved. I'm not sure about the 
> meaning of "bottom" and "top" types, but I think that with a 
> few non-breaking changes, it can be made to logically be the 
> polar opposite of typeof(assert(0)):
>
> -Where any type would be convertible to `typeof(assert(0))`, no 
> type is convertible to `void`.

Sounds good.


> -Where no type is convertible from `typeof(assert(0))`, any 
> type could be made convertible from `void`, the only possible 
> value of void converting to target type's `.init` value.

Consider:

   int n = foo();

A refactoring changes foo() from returning int to returning void. 
Now n is 0, and the type system is not helping me figure out 
what's wrong.

On a more theoretical level, void's set of possible values 
contains exactly one value, and that value is not int.init, 
string.init or myStruct.init - it's void.init.


> -Where a pointer to `typeof(assert(0))` can point to nothing, a 
> pointer to `void` can point to anything.

> -Where `typeof(assert(0))`, being capable of representing any 
> type possible without loss of information, would have infinite 
> size (and thus be impossible), `sizeof(void) == 0`, so it is 
> possible even in systems with no memory at all.

If void.sizeof == 0, then any void[], regardless of element 
count, would point to a memory region 0 bytes in size. This 
conflicts with your previous point.

I'm not averse to making void a unit type, but there seems to be 
some corners your design doesn't consider.

--
   Simen