On Sat, Aug 26, 2023 at 6:25 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I reply in series to Jason, Connor, Thiago and Sebastian below.
>
>
> On Sat, Aug 26, 2023 at 2:55 PM Jason McKesson wrote:
> >
> > The thing you actually seem to be wanting is some kind of fenced code
> > block that just turns off the C++ object model entirely, replacing it
> > with... well, something else. Because here's the thing: the C++ object
> > model is what defines what happens when you do stuff with object in
> > C++. So once you turn off the C++ object model, it is entirely unclear
> > how to interpret the meaning of *any* code or what its expected
> > behavior ought to be.
>
>
> We were getting on fine 25 years ago with C++98 before all this
> 'start_lifetime_as' stuff came out.
>
> Let me try get to the point here about what the purpose of applying
> the "__verbose" marker to a function is. Take the following
> translation unit as an example:
>
> extern bool SomeFunc(int);
>
> void Func(void)
> {
> for ( int i = 0; i >= 0; ++i )
> {
> if ( SomeFunc(i) ) break;
> }
>
> SomeFunc(-1);
> }
>
> A clever compiler won't bother checking if "i >= 0", because it's
> undefined behaviour for signed integers to overflow, so it would be
> optimised to:
>
> extern bool SomeFunc(int);
>
> void Func(void)
> {
> for ( int i = 0; SomeFunc(i); ++i )
>
> SomeFunc(-1);
> }
>
> But the '__verbose' marker on a function tells the compiler:
> "Inside the body of this function, if you detect the potential for
> undefined behaviour, don't take any liberties that you normally
> wouldn't take if such potential hadn't been detected".

That's not a thing the standard can say.

You don't seem to understand yet that the standard does not tell
compilers what to do. It's not a list of instructions about what the
compiler may and may not do. The standard defines behavior and
implementations implement the behavior as defined by the standard. The
standard can only constrain the behavior of an implementation by
*defining* what that behavior means. It cannot constrain undefined
behavior because... it's *undefined*.

As such, there is no standard concept of "liberties" that the
"compiler" may or may not take. There are no categories of undefined
behavior, where some behavior is maybe a bit undefined but others is
*really* UB. It's just undefined behavior.

What you're asking for is not something the standard can do. It's
something *implementations* of the standard may do, but even that is
pretty meaningless because there are no right answers.