4 ms·

I see what you mean for -> although personally I haven't missed it (I spent many years writing C) I don't write much pointer twiddling in Rust so I'm the wrong

I see what you mean for -> although personally I haven't missed it (I spent many years writing C) I don't write much pointer twiddling in Rust so I'm the wrong person to have an opinion. However surely the aliasing is actually a problem and so MIRI is annoyed because what you wrote might be wrong? If we hang on to (*node).first_next() but somehow node changes, we're no longer talking about the same thing, it's exactly the aliasing problem. I'd have to (which I have not) examine in detail how your code works to offer an opinion beyond speculation, but I think my instinct is sympathy for the "Don't write aliases" approach.

josephg 1y ago
> I think my instinct is sympathy for the "Don't write aliases" approach. Yes, requiring that nothing alias it’s much more conceptually elegant. But as I said, in practice it makes programming extremely treacherous. There are no warnings when you alias. No errors. 99% of the time you’ll get a working program with no bugs every time you build. You’re just - quietly - at the whim of llvm. Maybe it won’t compile correctly on some other architecture. Maybe a minor compiler bump, or different flags, will make your program totally broken. The only way to discover there’s even a potential problem is by running the code through MIRI. I get why it’s like this but I think it’s a mistake. I think unsafe rust should be at least as expressive and pleasant to work with as C. Having quiet foot guns here seems antithetical to rust’s philosophy of safe ergonomic programming.