Bottom Type--Type Theory

[Dukc]

On Thursday, 17 January 2019 at 00:09:50 UTC, H. S. Teoh wrote:
> So you see, `void` is a rats' nest of special cases and ad hoc 
> monkey-patched semantics that's inconsistent with itself.  
> Sometimes it behaves like a unit type, sometimes it behaves 
> like a bottom type, and sometimes it behaves like a top type, 
> and none of these usages are consistent with each other, nor 
> are they truly consistent with themselves either.

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`.
-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.
-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.
-`void` variables should be valid syntax, that can be assigned 
(no-op at machine level) and compared (lowered to literal `true` 
by compiler) to each other.
-Compiler would be free to decide any non-null address for a void 
variable. Since dereferencing a pointer to void will only result 
in void, which never uses any memory, it cannot do any harm.