[charlotte-fyi]

> and if it’s after the code I care about observing, it doesn’t matter

That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior you are no longer capable of observing the code you care about correctly.

[carlmr]

I feel like people like OP, who don't understand UB and its consequences, would benefit the most from the strict compiler, but can be bothered the least to learn what it's saying.

[withinboredom]

I understand what it’s saying. I just disagree that it has to be done for every compilation. Often, as a human, I can reason that it is safe (or reasonably safe for what bug I am attempting to fix). I’m not talking about released software, I’m talking about software I am developing in the moment that I am developing it.

[timschmidt]

> as a human, I can reason that it is safe

This assumption has been tested at societal scale and proven false, at great cost.

[withinboredom]

I didn’t say I could do it successfully or that it even matters. Only that I am able to and execute, at my own discretion. You know, have agency.

[timschmidt]

This is exactly the attitude that makes me very happy that the Rust compiler is so strict. The people who need the training wheels most are the same folks who think they don't.

[withinboredom]

I mean, I fix bugs. Rewriting half the program just to verify the bugs are fixed is overkill before opening a PR (you know, verifying the approach, validating assumptions, manual tests, the stuff you do long before actually fixing the bug, etc). But comments like these and others on this thread is exactly why I may not in the future. This is a rather toxic thread. People seem to treat this thing as a religious artifact without giving a single reason grounded in practical computer science and software engineering.

[withinboredom]

It isn’t about the “after” it’s about the “before”. For example, if I insert some code that divides by zero “later” but causes some new behavior I’m interested in, that’s what I’m interested in. The divide by zero is annoying, but can be addressed later.

If the compiler forced me to check ever integer division wasn’t a divide by zero, that would be annoying in this case. The borrow checker is like this. It forces you to rewrite entire application code just to see if some new behavior fixes a bug, in the name of safety, without realizing that “for just this execution, I don’t care about safety.”

[piaste]

The parent's point is that there is no separation between "before" or "after", it all ends up in the same artifact. And when you write invalid code, you have no guarantees about the compiled artifact anymore.

There is an example of C code (fairly sure I saw it on HN) where violating a UB rule caused an entirely dead piece of code to suddenly be executed, which even made sense after explanation.

In the linked article, Rust-minus-borrow-checker somehow caused an invalid number to appear inside a compile-time static array.

Sure, poke around the results of UB all you want. Curiosity is great. But at some point you'll have to compile your hypothesis as part of valid code, to be able to trust the results.

[dtn]

I think you're referring to this one: https://blog.tchatzigiannakis.com/undefined-behavior-can-lit...

Bonus read: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...

[piaste]

Thanks for the link! I think I had in mind another one, where the UB fuckery happened at a lower level (I think you ended up with a semicolon/brace effectively "disappearing"?). But that's a good example too.