proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 21:32:31 UTC, Walter Bright wrote:
> On 7/9/2017 1:24 PM, Meta wrote:
>> Another case that we should probably just statically disallow:
>> 
>> alias ImmutableBottom = immutable Bottom; //Ditto for shared, 
>> const, etc.
>> 
>> This obviously doesn't make any sense anyway.
>
>
>
> Wouldn't `immutable(Bottom)` simply resolve to `Bottom`?

I was thinking about that (and in fact, making Bottom a "viral" 
type in the same way that NaN is a viral value), but it's not 
really worth it and we might as well make it an error. It can't 
occur in any template code if we disallow passing Bottom as a 
template argument, e.g., the following would fail:

alias Pointificate(T) = T*;
alias Immutable(T) = immutable T;

//Error: cannot pass Bottom as a template type argument
alias PointerToBottom = Pointificate!Bottom;
alias ImmutableBottom = Immutable!Bottom;

So the only place left where we could make a modified Bottom type 
would be doing `alias Immutable Bottom = immutable Bottom` and 
the like. It doesn't really matter either way, I don't think, but 
we might as well keeps things streamlined and just disallow 
everything to do with Bottom that we don't like. Unless there's a 
compelling reason to be able to apply immutable, shared, etc. to 
Bottom (and I don't see how there can be as you can never have a 
value of type Bottom that could be immutable, shared, etc. 
anyway) we should just disallow it.

Some functional languages do allow you to create things like 
`Either!(T, Bottom)` (from the Reddit thread: "Sometimes you have 
a generic procedure over a sum type and you want to pass it a 
single thing: `Either a Bottom` is isomorphic to a.") but I don't 
see a reason for us to ever need to do that.