[rcoveson]

Speaking from a place of long-term frustration with Java, some compiler authors just absolutely hate exposing the ability to hint/force optimizations. Never mind that it might improve performance for N-5 and N+5 major releases, it might be meaningless or unhelpful or difficult to maintain in a release ten years from now, so it must not be exposed today.

[recursivecaveat]

I once exposed a "disableXYZOptimization" flag to customers so they could debug a easier without stuff getting scrambled. Paid for my gesture for the next year signing off on release updates, writing user guide entries, bleh.

[Eridrus]

So it's better to hardcode your specific library name and deal with the same issue after people have reverse engineered it and started depending on it anyway?

[MichaelZuo]

That seems valid for customers expecting a warranty or support. But they should allow it if customers waive all such in writing.

[Dylan16807]

Warranty and support specifically for that flag? Because I don't see how general warranty and support requires keeping any hint flags forever.

[shadowpho]

If you remove the hint flag peoples build will break

[Dylan16807]

Doesn't need to, it can acknowledge and ignore the hints.

[shadowpho]

True, but there might be more problems — like if you drop support their run time will be slow because they rely on this flag and they are unhappy

[Dylan16807]

The premise of removing the flag is that it's useless or a problem. If it's still causing a big speed boost somewhere then you need to figure something out, but the core scenario here is that it's obsolete.