proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/13/2017 01:25 PM, Timon Gehr wrote:
> On Wednesday, 12 July 2017 at 14:23:15 UTC, Andrei Alexandrescu wrote:
>> 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.
>> ...
> 
> I might do that, however there are a couple of open questions (see below).

Sorry missed those... let's see:

> It's perfectly fine to have a type of types which is its own type, 
> especially if you allow non-termination.

<nod>

> I'm saying the D notion of subtyping is a bit messy because memory 
> layout matters and subtyping and implicit conversion are not the same 
> thing. Anyway, my assertion that Bottom cannot be a subtype of all other 
> types was actually incorrect: the compiler does not need to generate 
> code for implicit conversion from Bottom to some other type, so it can 
> be treated as a subtype.

<nod>

> typeof(assert(0))* and typeof(assert(0))[] will hence be subtypes of all 
> other pointer and array types respectively.

Wow. Cool!

> An issue is that we already have typeof(null). typeof(null) and 
> typeof(assert(0))* are two ways to specify almost the same thing. One 
> question is whether typeof(assert(0))* and typeof(null) should be the 
> same, or if the former should not implicitly convert to class references.
> I have also argued in the past that there should be a separate 
> typeof([]). This role would now be filled by typeof(assert(0))[]. 
> However, changing the type of '[]' may break code.

You're on to something here. Perhaps we go the inverse route and define 
the bottom type as typeof(*null). Would that simplify matters? There is 
some good consistency about it:

null: a pointer to anything. But can't be dereferenced.
*null: well, therefore... anything. But can't be created.

The latter is a mere consequence of the former.

> I think the DIP should introduce conversion from the start, as 
> conversion is easy to support. It is simple to support in the front end 
> and the code gen for it is literally to emit nothing.

Fantastic. Please kick it off. Thanks!!


Andrei