• d-bugmail puremagic.com (37/37) Sep 27 2023 https://issues.dlang.org/show_bug.cgi?id=24167

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=24167

          Issue ID: 24167
           Summary:  noreturn compiles because of noreturn
           Product: D
           Version: D2
          Hardware: x86_64
                OS: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: issues.dlang jmdavisProg.com

This code compiles

string foo()  noreturn
{
    return null;
}

It's not noreturn, and it wasn't correctly marked as noreturn, since the spec
says that noreturn is a return type rather than an attribute, but the
definition of noreturn in object.d:

alias noreturn = typeof(*null);

makes it possible. I just ran into some code today which incorrectly used
 noreturn, and it didn't catch what noreturn is supposed to catch (even though
the person writing the code thought that that's what it was doing).

Strictly speaking, I'm not sure that it's a bug that the alias for noreturn
makes it possible to use  noreturn, but it seems error-prone for folks who
misremember (or mislearned) how noreturn is supposed to work - and as I
understand it, there was discussion of implementing  noreturn before we ended
up with noreturn, so it's not entirely surprising that someone would make this
mistake.

So, I would argue that ideally, we would disallow  noreturn, though given how
noreturn is defined, I don't know what a good way to do that would be. Perhaps
typeof(*null) should just be disallowed for attributes, though I don't know if
special-casing that is any different from special-casing  noreturn to block it.
But maybe actual compiler people will have a better idea.

--