proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/12/2017 05:32 AM, Timon Gehr wrote:
> On 09.07.2017 23:45, Meta wrote:
>> ...
>> Another case that we should probably just statically disallow:
>> ... > This obviously doesn't make any sense anyway
>> ... > I don't see a reason for us to ever need to do that
> Sorry, but this thinking has no place in type system design. This is 
> precisely how you create a convoluted nonsensical mess.

Timon, I think you're very well positioned to author a DIP on this. 
Getting through acceptance on your static foreach DIP seems to not 
require a lot of extra work.

> Every type is peculiar. That's essentially the point of having
> types. There is not really a reason to invent a peculiarity ordering
> and then add additional special casing for types deemed more
> peculiar. (I.e., creating different types of types based on an
> informal judgment of peculiarity.)
I seem to recall Haskell calls those "kinds".

> In D, subtyping is messy anyway, as you cannot have a subtyping
> relationship between values with different memory layout. Hence in D,
> Bottom would not actually be a subtype of all other types.

It's a point, and it would make the implementation easier, but it would 
be a departure from theory. Also it makes user code a tad more awkward. 
Consider:

typeof(assert(0)) abort(const(char)[] message);
...
int fun()
{
    int x;
    ...
    return x != 0 ? 1024 / x : abort("Error: calculation went awry.");
}

I guess such expressions can be rewritten into separate statements:

if (x != 0) return 1024 / x;
abort("Error: calculation went awry.");

and then the compiler figures there's no need for a return following the 
call to abort.

Perhaps a solid plan is to start with a DIP that does not introduce 
conversion and then experiment with the result for a while. What do you 
think?


Andrei