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: nob...@puremagic.com
Reporter: issues.dl...@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.
--
