Hi SG12

On Thu, May 6, 2021 at 4:47 PM JF Bastien via SG12 <sg12_at_[hidden]>
wrote:

> 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?*
>
> Shafik's paper has a short mention here: http://wg21.link/P1705#stmtreturn
> http://wg21.link/p2234 <http://wg21.link/p2234> also talks about this.
>
> The specific wording <http://eel.is/c++draft/stmt.return#2.sentence-8>:
>
> 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 <http://wg21.link/p0627> (waiting
> for an update post LWG feedback
> <https://github.com/cplusplus/papers/issues/275>) 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.
>
> 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
S.Scott.Schurr_at_[hidden]


> JF
> _______________________________________________
> SG12 mailing list
> SG12_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> Searchable archives: http://lists.isocpp.org/sg12/2021/05/index.php
>