Hi SG12

On Thu, May 6, 2021 at 4:47 PM JF Bastien via SG12 <sg12@lists.isocpp.org> wrote:
(resending.. again... with the right address.... darned email UB)

A recent MISRA discussion makes me wonder: why do we keep this UB around?

Shafik's paper has a short mention here: http://wg21.link/P1705#stmtreturn
 http://wg21.link/p2234 also talks about this.

Flowing off the end of a constructor, a destructor, or a non-coroutine function with a cv void return type is equivalent to a return with no operand. Otherwise, flowing off the end of a function other than main or a coroutine results in undefined behavior.

We have [[noreturn]] to help express programmer intent around this, and we've got a proposal for std::unreachable (waiting for an update post LWG feedback) which IMO allows expressing intent which [[noreturn]] doesn't express.

Compilers diagnose when functions can't be proved to return, and I wouldn't work on a codebase without this diagnostic enabled as an error. Is there a valid reason to keep this UB around? I get that exceptions and longjmp and exit make this diagnostic conservative, but I'd rather have programmers express intent with [[noreturn]] and std::unreachable, which as far as I know compilers diagnose 100% accurately when used to express intent. It seems like we're keeping UB around when we have better tools ([[noreturn]] and std::unreachable) to opt-in to UB.


I wanted to leave time for someone else to respond.  But 24 hours have passed and no one else has responded.

Personally, the only reason I can imagine that the committee has not addressed this problem is that no one has written the paper and most folks on the committee don't consider it to be a significant problem.

If someone wrote the paper I would certainly support it wholeheartedly.  This is very much worth doing.

Three stumbling blocks for such a paper might be:

1. Bikeshedding.  How should the "I'm explicitly telling the compiler that I think my code can't fall off this end" decoration be spelled?

2. It needs a source backward compatibility story.  People need to modify their source files to comply with the new rule.  What do we tell those folks?  Do we provide a transition period?

3. Maybe there's an issue convincing the committee that this is a problem worth addressing? Some committee members may consider this to be a "niche problem" and solving it provides more pain than benefit

But, in my opinion, we should do this.  Consider me strongly in favor.

Scott Schurr

SG12 mailing list
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Searchable archives: http://lists.isocpp.org/sg12/2021/05/index.php