proposed @noreturn attribute

Olivier FAURE via Digitalmars-d digitalmars-d at puremagic.com
Mon Jul 17 08:39:30 PDT 2017


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()?".


More information about the Digitalmars-d mailing list