On Monday, 10 July 2017 at 00:34:54 UTC, Andrei Alexandrescu
wrote:
`typeof(null)` actually has one valid value and doesn't crash
the program when when you try to create an instance of it. We
should not treat this the same as `typeof(null)`.
Agreed (with the mention it's not in contradiction with the
above). -- Andrei
That was in response to:
Similarly, I don't recall ever there being a problem with
typeof(null)*, typeof(null)[], people complaining they passed
typeof(null) to a template where it did bad things, etc.
My point was that I don't agree with the analogy as there really
isn't any similarity between typeof(assert(0)) and typeof(null).
There are no problems with stuff like typeof(null)* etc. because
for the most part it's just a regular type, unlike Bottom.
Although now that you mention it, there might be some interesting
uses for a pointer/array that we statically know can only be null
(none that I can think of OTOH though).
I still think we should err on the side of disabling stuff like
`immutable Bottom`, `Bottom*`, `Nullable!Bottom`, etc. until we
fully understand the ramifications. We also cannot allow
struct/class members of the type Bottom for obvious reasons.
Interestingly enough, unions would conceptually be okay, and you
would statically know that a union such as `union IntOrBottom {
int n; Bottom b; }` can only ever contain an int. Therefore,
IntOrBottom could safely be aliased away to just int (syntactic
differences between working with a union vs. working with an int
aside).
We also need to disallow `enum Sneaky: Bottom { val }` and `enum:
Bottom { val }`. I don't know how enums are implemented in the
compiler so it may be a non-issue. `enum Okay: Bottom {}` is fine
and Okay could just alias itself away (but we should still
disable it to prevent confusion). `enum: Bottom {}` makes no
sense so we should prevent that as well.
