Hello 🐉 UB 🐲,
(resending.. again... with the right address.... darned email UB)
A recent MISRA discussion makes me wonder: why do we keep this UB around?
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.
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.
Thanks!
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
SG12@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Searchable archives: http://lists.isocpp.org/sg12/2021/05/index.php