@gassahara@mstdn.io @amiloradovsky@functional.cafe Look at em trying to dodge bugs!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87605
Good thing there's always the friendly neighborhood standard expert to back you up.

And again you disregard us poor humans, while I'm trying to convince you there is nothing else. There is only us. Abstractions are not just nice for us there are our only choice to do anything, and we are doing everything that there is in this industry. That's why good tools to write good abstractions are important. For example, I often see indirection or runtime type information used in C due to lack of proper type system or generics. Do you want userdata without indirection? Do you want callbacks without indirection? C++ type system and generics got you covered. And there is much more in the same vein. With C there is general tendency to try to break away from the limitations of the language by pushing abstraction out of it, either to the runtime or to external tools (like code generators). You shouldn't be generating code, compilers generate code, become a compiler developer instead, add your language extension to gcc (or llvm, if you are a pussy) then try to standardize it and get roasted. Do good for the humanity (likely not approved by your current employer) not for your job security, by writing code no one else can read. Don't do it out of altruism but out of professional pride, which would be repeatedly beaten out of you by the standard's committee.

Sure be aware of your system, provide a proper initial guess and number of iterations for Babylonian method that makes sense for your system or use case, but do not implement the basic algorithm over and over again, getting it wrong half the time. I would even say write a compile time function to compute the initial guess, instead of doing it on paper and leaving a mysterious magic number behind. If the compiler does not optimize your obvious expressive abstraction, become a compiler developer again, or nag them until they fix it.

For every barely exploitable spectre, there are probably a dozen of embarrassingly exploitable software vulnerabilities, not to mention that it is our culture of writing hardware specific code that drove the hardware engineers to the overcomplicated designs that cause these problems, forcing them to optimize old instruction sets instead of developing new ones. Not our fault for doing that initially, is our fault for sticking with it till today, and planning to stick with it in the future.

Yet even in our current climate the fact that the compilers (written by humans) can beat people at optimizing certain common abstractions is a testament to the effectiveness of the approach. They are even adding GPU backends for them. I for one am waiting for a new wave of verilog backbends.