←back to thread

Tree Borrows

(plf.inf.ethz.ch)
565 points zdw | 1 comments | 09 Jul 25 14:40 UTC | HN request time: 0.206s | source
Show context
jcalvinowens ◴[09 Jul 25 18:21 UTC] No.44513250[source]▶
> On the one hand, compilers would like to exploit the strong guarantees of the type system—particularly those pertaining to aliasing of pointers—in order to unlock powerful intraprocedural optimizations.

How true is this really?

Torvalds has argued for a long time that strict aliasing rules in C are more trouble than they're worth, I find his arguments compelling. Here's one of many examples: https://lore.kernel.org/all/CAHk-=wgq1DvgNVoodk7JKc6BuU1m9Un... (the entire thread worth reading if you find this sort of thing interesting)

Is Rust somehow fundamentally different? Based on limited experience, it seems not (at least, when unsafe is involved...).

replies(11): >>44513333 #>>44513357 #>>44513452 #>>44513468 #>>44513936 #>>44514234 #>>44514867 #>>44514904 #>>44516742 #>>44516860 #>>44517860 #
ralfj ◴[09 Jul 25 18:28 UTC] No.44513333[source]▶
I would agree that C's strict aliasing rules are terrible. The rules we are proposing for Rust are very different. They are both more useful for compilers and, in my opinion, less onerous for programmers. We also have an actual in-language opt-out: use raw pointers. And finally, we have a tool you can use to check your code.

But in the end, it's a trade-off, like everything in language design. (In life, really. ;) We think that in Rust we may have found a new sweet spot for this kind of optimizations. Time will tell whether we are right.

replies(3): >>44513873 #>>44514788 #>>44521382 #
1. jcalvinowens ◴[10 Jul 25 14:16 UTC] No.44521382[source]▶
Thanks for replying Ralf. I'm barely qualified to have an opinion about these things, if I am at all :)

> The rules we are proposing for Rust are very different. They are both more useful for compilers and, in my opinion, less onerous for programmers.

My question was too vague, what I meant to ask was: what aliasing optimizations will be possible in Rust that aren't possible in C?

Example 18 in the paper is one, if I'm understanding it. But that specific example with a pointer passed to a function seems analogous to what is possible with 'restrict' in C, I'm struggling to come up with more general examples that don't involve gratuitous globals.

It seems to me like having to allow for the possibility of unsafe constrains the ability to do "heroic" optimizations such as what jcranmer described elsewhere in the thread. If that is true to some extent, is there a future where Rust might optimize more aggressively if the programmer promises not to use unsafe anywhere in the program? That's something I've always been curious about.