Fear of Compiler Magic

[Dennis]

On Saturday, 3 August 2024 at 17:02:55 UTC, Walter Bright wrote:
> The transformation won't compile if the call is marked @safe, 
> and won't compile with the various proposals to increase the 
> default safety-ness.

This is an interesting aspect that I forgot to mention: Whenever 
I bring up such examples of problematic cases resulting from 
'magic', the defense is often akin to: "Sure, it fails in that 
theoretical / pathological case, but when are you going to find 
that in REAL code?"

Which can be fair. Like I said, a bit of magic doesn't always 
have to be problematic. And while I can't tell you when or how 
these problem cases are going to crop up, do beware that there 
might just be plenty of opportunity, just from a statistical 
standpoint.

It's like Intel saying, in response to the [Pentium FDIV 
bug](https://en.wikipedia.org/wiki/Pentium_FDIV_bug): "Well, when 
are you going to divide 4195835 by 3145727 needing all the 
precision? Give me an example of when you would divide those 
specific numbers in a REAL application."

That's hard to answer upfront, but with enough users doing enough 
floating point math, eventually you get [some great 
stories](https://www.youtube.com/watch?v=22FU31ZUgNA&t=1519): 
When working on Quake, Michael Abrash spent hours tracking down a 
graphical glitch, until finding out with the help of a friend 
from Intel that it was the infamous hardware bug.

Going back to printf, it's possible hardly anyone will ever hit 
this problem. But when eventually there's thousands of calls to 
magic printf out there (or snprintf which still can't be called 
in `@safe` code!), each one is a contender to be part of that one 
spectacular failure. That's why I used the word "minefield": 
There's no guarantee of things blowing up, it depends on the 
density of mines and the amount of people crossing.

So you could try some sort of risk assessment for magic features, 
but I prefer to just avoid them as much as possible and look for 
alternatives.

> It is in the same box as:

That example is different, because the first program wasn't 
correct to begin with. Or if it were, then the refactoring would 
result in the second program also being correct. In my example, 
only the first program was correct.