Maybe [[debugger_editable]] would clarify the idea most clearly? If you don't add debug information (e.g. no -g switch) then the compiler could optimize it away, but if you add debug info then it keeps reading it regardless of other optimizations.
-------- Original Message --------
On Jun 10, 2022, 14:27, Henry Miller via Std-Proposals wrote:

> On Fri, Jun 10, 2022, at 10:34, Lénárd Szolnoki via Std-Proposals wrote:
>> Also, I would like to add that this is nothing more than trading one
>> language quirk that happens to be an optimisation barrier to an other
>> (volatile vs function calls across TUs). If we deem optimization
>> barriers to be useful for debugging/benchmarking, then having them as
>> attributes makes perfect sense.
>
> In addition to better communicating what is going on, an attribute instantly implies [likely] or [not likely] which makes it better. It also allows other optimizations that volatile turns off even though they don't matter. The attribute also allows an implementation to add some form of "but this really is release a where a debugger will not be run" compile flag (different from relWithDebInfo which I ship with) thus eliminating the code. It also allows an implementation to skip the if, and put something into the debug information so the debugger just sets a breakpoint where the if would have been and jumps to the code.
>
> Those are 3 options that I can think of. I'm sure there are people smarter than me who can think of even more if they put for the effort. However so long as we constrain our implementation to "you don't know what is going on so don't optimize at all" it isn't worth thinking about what else can be done if more information was granted.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals