proposed @noreturn attribute

[Meta via Digitalmars-d]

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.