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.
Comment #1 by robert.schadek — 2024-12-13T19:31:01Z