proposed @noreturn attribute

[Patrick Schluter via Digitalmars-d]

On Monday, 17 July 2017 at 15:39:30 UTC, Olivier FAURE wrote:
> On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu 
> wrote:
>>> 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'd really prefer if you avoided the whole `typeof(assert(0))` 
> thing.
>
> First off, it's way too verbose for a simple concept. In 
> general, code is much more readable when you can read functions 
> as `Type functionName(args)`, rather than template-style 
> `expr(valueof!(thing + otherThing).typeof) functionName(args)`, 
> so I think it would be better not to encourage adding more 
> expressions as return types.
>
> I think the following:
>
>     noreturn_t logThenQuit(string message)
>
> is much more readable and obvious (especially to a beginner) 
> than:
>
>     typeof(*null) logThenQuit(string message)
>
> Of course, you could implement typeof(*null); and also add 
> noreturn_t as an alias; it might be a good compromise; I'd 
> still dislike it because it encourages people to use the 
> verbose hard to understand version.
>
> The second reason I don't like it is that I feel it's just 
> trying to be clever for the sake of cleverness. I don't think 
> we need a language feature that perfectly matches the idea of 
> not returning from a function on a deep, philosophical level; 
> we just need a way to tell the type system "Hey, this function 
> doesn't return!".
>
> I don't think `typeof(*null)`, or `typeof(assert(0))` brings 
> any advantage in term of real life user code, and I don't think 
> it's worth the confused users that would look at code and go 
> "Uh? What is the type of *null?" or "I thought assert was void! 
> What would you get the type of assert()?".

Yes, this!