On Sat, Jun 11, 2022 at 1:08 PM Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Sat, Jun 11, 2022 at 2:40 AM Bo Persson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On 2022-06-10 at 23:09, Arthur O'Dwyer via Std-Proposals wrote:
>> >
>> > I think I need to re-post this paragraph.
>> >
>> > Here's another way to look at it: *"Optimization barrier" is not a
>> > first-class principle.* Instead, the fundamental organizing principle is
>> > *"The tool can't optimize what it can't see."* So, if you really really
>> > want something not to be optimized, then you simply mentally reduce the
>> > problem to "How can I make my optimizing tool /not see/ this function?"
>>
>> So perhaps what we need is a [[dont_look]] directive?
>
>
> If the optimizing tool you're trying to hide from is specifically a tool that consumes .cpp files (and recognizes that directive), then yeah, sure.
> If it's a tool like Green Hills' elxr that consumes .o files containing binary code, then of course putting a source-level directive won't work.
> If it's a Perl script that doesn't understand `[[` syntax, then of course that won't work.
> You always need to think about "What am I actually trying to accomplish here? What is my goal? What optimizing tool am I trying to interact with?"

... why? Why do I, as a user, care "what optimizing tool am I trying
to interact with?"

Remember the problem in question: I wrote code which by appearances
ought to do X, but for reasons I really don't care about, it does Y.
What I want is to make it do X, to do what the literal text says to
do.

What optimizing tool is responsible for the change from X to Y is
utterly irrelevant to me. It's a detail I do not *want* to care about.
What I want is to be able to say "do X".

Having to think about what tool exactly it is that's responsible for
the problem is the wrong way of looking at solving the problem.