> You're obviously correct, but I think this ignores downstream costs of sufficiently magical compilers. If my compiler tunnels into a parallel universe, execut

> You're obviously correct, but I think this ignores downstream costs of sufficiently magical compilers. If my compiler tunnels into a parallel universe, executes the code there, and returns the result, that's fine, but it's going to be enormously painful to debug. > Obviously very few developers (including myself) have an appropriate mental model of highly complex, speculative processor architectures that end up executing their code, but I do think there is at least some benefit to having a correspondence between the code you write and the code the compiler generates. It’s not really clear to me why you think this? Or at least, it’s not clear to me how you can write this without levelling the same complaint against essentially any C compiler written after the mid 1980s? Because for all the hand—wringing in the comments here about compilers generating code that doesn’t do what your C said it would do in the way you wrote it, that ship sailed decades ago. That quaint little integer addition loop you write in C will, as like as not, be exploded by the compiler into an unrolled stream of SIMD instructions and packed registers that doesn’t resemble what you wrote in the least, which the CPU may then further scramble and interleave, resulting in nothing remotely like what a naive person might imagine is a reasonable translation of what you wrote – and yet, debuggers remain broadly useful tools. And people have for decades now shown a strong desire to enthusiastically and with great speed drop compilers in favour of newer ones that performed better optimizations, which is to say, people have shown a strong preference for compilers that are good at generating code that looks nothing like what you wrote, provided the results are the same and the performance is as fast as possible. Turning a copy into passing a pointer that may later copy if and only if the compiler sees the possibility of a write coming is, in terms of modern optimizations, an absolutely conservative optimization that doesn’t routinely happen only because platform ABIs unnecessarily rule it out. Far from being a bridge too far, in terms of modern compiler behaviour it’s simple and low-hanging fruit which isn’t exploited even though far more exotic tricks are already the rule of the day.