frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Open in hackernews

Tree Borrows

https://plf.inf.ethz.ch/research/pldi25-tree-borrows.html
280•zdw•5h ago

Comments

pvg•4h ago
The Stacked Borrows mentioned had threads in 2020 and 2018

https://news.ycombinator.com/item?id=22281205

https://news.ycombinator.com/item?id=17715399

kibwen•4h ago
Recent blog post from Ralf Jung providing some extra context: https://www.ralfj.de/blog/2025/07/07/tree-borrows-paper.html

Bonus: recent talk from Ralf Jung on his group's efforts to precisely specify Rust's operational semantics in executable form in a dialect of Rust: https://youtube.com/watch?v=yoeuW_dSe0o

wavemode•4h ago
From the paper:

> The problem with unsafe code is that it can do things like this:

    fn main() {
        let mut x = 42;
        let ptr = &mut x as *mut i32;
        let val = unsafe { write_both(&mut *ptr, &mut *ptr) };
        println!("{val}");
    }
No it can't? Using pointers to coexist multiple mutable references to the same variable is undefined behavior. Unless I'm just misunderstanding the point they're trying to make here.
seritools•4h ago
"can do things" in this case doesn't mean "is allowed to do things".

"Unsafe code allows to express the following, which is UB:"

ehsanu1•4h ago
I believe that's exactly the point: it's too easy to violate constraints like not allowing multiple mutable references. Unsafe is meant for cases where the validity of the code is difficult to prove with rust's lifetime analysis, but can be abused to do much more than that.
pavpanchekha•4h ago
The point of this work is to pin down the exact boundaries of undefined behavior. Certainly the code above is accepted by the Rust compiler, but it also breaks rules. What rules? In essence, we know that:

- Anything accepted by the borrow checker is legal

- Unsafe can express illegal / undefined behavior

- There's some set of rules, broader than what the borrow checker can check, that is still legal / defined behavior

The goal of this line of work is to precisely specify that set of rules. The outlines are clear (basically, no writable pointers should alias) but the details (interior pointers, invalidation of iterators, is it creating or using bad pointers that's bad, etc) are really hard. The previous paper in this series, on Stacked Borrows, was simpler but more restrictive, and real-world unsafe code often failed its rules (while still seeming correct). Tree Borrows is broader and allows more while still being provably safe.

ralfj•4h ago
> allows more while still being provably safe.

Note that we have not yet proven this. :) I hope to one day prove that every program accepted by the borrow checker is compatible with TB, but right now, that is only a (very well-tested) conjecture.

sunshowers•1h ago
Hi Ralf! Congrats to you all for the PLDI distinguished paper award.
ralfj•1h ago
Thanks :-)
oconnor663•4h ago
You're already getting a lot of replies, and I don't want to pile on, but I think the clearest way to see the intent there is at the start of the following paragraph:

> Given that aliasing optimizations are something that the Rust compiler developers clearly want to support, we need some way of “ruling out” counterexamples like the one above from consideration.

ralfj•4h ago
> Using pointers to coexist multiple mutable references to the same variable is undefined behavior.

Yes, but which exact rule does it violate? What is the exact definition that says that it is UB? Tree Borrows is a proposal for exactly such a definition.

"code can do things like this" here means "you can write this code and compile it and run it and it will do something, and unless we have something like Tree Borrows we have no argument for why there would be anything wrong with this code".

You seem to have already accepted that we need something like Tree Borrows (i.e., we should say code like this is UB). This part of the paper is arguing why we need something like Tree Borrows. :)

GolDDranks•2h ago
> Unless I'm just misunderstanding the point they're trying to make here.

You misunderstand the word "can". Yes, you can, in unsafe code, do that. And yes, that is undefined behaviour ;)

https://play.rust-lang.org/?version=stable&mode=debug&editio...

pil0u•3h ago
Just realised that one of the author, Neven Villani, is Cédric Villani's (Fields Medal 2010) son. Apples don't fall far from the tree, indeed.
tandr•2h ago
> Apples don't fall far from the tree, indeed.

And one could say that they borrow from the tree some of their qualities. Sorry, couldn't resist.

Yoric•2h ago
Hey, I used to have an office close to the dad's :)

That's before he went into politics, though.

fuhsnn•3h ago
I wonder if Rust or future PL would evolve into allowing multiple borrow checker implementations with varying characteristics (compile speed, runtime speed, algorithm flexibility, etc.) that projects can choose from.
speed_spread•2h ago
I cannot imagine how that would work. You couldn't combine code that expect different borrowing rules to be applied. You'd effectively be creating as many sub-dialects as there are borrow checker implementations.
vlovich123•1h ago
FWIW technically the rules are the same. How they go about proving that the rules are upheld for a program is what would be different.
umanwizard•2h ago
What’s wrong with the compile or runtime speed of the current one?
pjmlp•2h ago
We already have that by having multiple approaches via affine types (what Rust uses), linear types, effects, dependent types, formal proofs.

All have different costs and capabilities across implementation, performance and developer experience.

Then we have what everyone else besides Rust is actually going for, the productivity of automatic resource management (regardless of how), coupled with one of the type systems above, only for performance critical code paths.

LelouBil•2h ago
I would love some sort of affine types in languages like Kotlin, it just makes cleaner code organization in my opinion.

Doesn't matter if it's purely "syntaxical" because the language is garbage collected, just the fact of specifying what owns what and be explicit about multiple references is great imo.

Some sort of effects systems can already be simulated with Kotlin features too.

Programming language theory is so interesting!

ChadNauseam•48m ago
> affine types (what Rust uses)

I'd just like to interject for a moment. What you’re referring to as "affine types", is in fact, Uniqueness Types. The difference has to do with how they interact with unrestricted types. In Rust, these "unrestricted types" are references (which can be used multiple times due to implementing Copy).

Uniqueness types allow functions to place a constraint on the caller ("this argument cannot be aliased when you pass it to me"), but places no restriction on the callee. This is useful for Rust, because (among other reasons) if a value is not aliased you can free it and be sure that you're not leaving behind references to freed data.

Affine types are the opposite - they allow the caller to place a restriction on the callee ("I'm passing you this value, but you may use it at most once"), which is not something possible to express in Rust's type system, because the callee is always free to create a reference from its argument and pass that reference to multiple functions..

ralfj•34m ago
I would say it is perfectly accurate to call Rust's type system affine. At its core, "affine" means that the type system has exchange and weakening but not contraction, and that exactly characterizes Rust's type system. See <https://math.stackexchange.com/questions/3356302/substructur...> for an explanation of what those terms mean (that's in the context of a logic, but it's the same for type systems via the Curry-Howard correspondence).

This is often explained via the "do not use more than once rule", but that's not the actual definition, and as your example shows, following that simplified explanation to the letter can cause confusion.

> because the callee is always free to create a reference from its argument and pass that reference to multiple functions..

Passing a reference is not the same thing as passing the actual value, so this does not contradict affinity.

0x000xca0xfe•2h ago
As I understand it the borrow checker only has false negatives but no false positives, correct?

Maybe a dumb question but couldn't you just run multiple implementations in parallel threads and whichever finishes first with a positive result wins?

vlovich123•1h ago
This presumes that checking composes which may not if you have orthogonal checker implementations. You might end up risking accepting an invalid program because part of it is valid under one checker, part under another, but the combination isn't actually valid. But maybe that's not actually possible in practice.
sunshowers•1h ago
That would result in ecosystem splitting, which isn't great.
pornel•49m ago
Rust already supports switching between borrow checker implementations.

It has migrated from a scope-based borrow checker to non-lexical borrow checker, and has next experimental Polonius implementation as an option. However, once the new implementation becomes production-ready, the old one gets discarded, because there's no reason to choose it. Borrow checking is fast, and the newer ones accept strictly more (correct) programs.

You also have Rc and RefCell types which give you greater flexibility at cost of some runtime checks.

Ericson2314•7m ago
What you actually want is the underlying separation logic, so you can precisely specify function preconditions and prove mid-function conditions, and the the optomizer can take all those "lemmas" and go hog-wiled, right up to but not past what is allowed by the explicitly stated invariants.

"Rust", in this context, is "merely" "the usual invariants that people want" and "a suite of optimizations that assume those usual invariants, but not more or less".

Voultapher•2h ago
Amazing work, I remember reading the Tree Borrows spec? on Nevin's website a couple years ago and being thoroughly impressed by how it solves some pretty gnarly issue quite elegantly. And in my experience [1] [2] it does indeed allow for sensible code that is illegal under Stacked Borrows.

[1] https://github.com/Voultapher/sort-research-rs/blob/main/wri... Miri column

[2] https://github.com/rust-lang/rust/blob/6b3ae3f6e45a33c2d95fa...

vollbrecht•2h ago
Hmm i just tested out the claim that the following rust code would be rejected ( Example 4 in the paper).

And it seams to not be the case on the stable compiler version?

  fn write(x: &mut i32) {*x = 10}
  
  fn main() {
      let x = &mut 0;
      let y = x as *mut i32;
      //write(x); // this should use the mention implicit twophase borrow
      *x = 10; // this should not and therefore be rejected by the compiler
      unsafe {*y = 15 };
  }
Arnavion•2h ago
Stacked borrows is miri's runtime model. Run it under miri and you will see the error reported for the `*x = 10;` version but not the `write(x);` version - "Undefined Behavior: attempting a write access using [...] but that tag does not exist in the borrow stack for this location".

rustc itself has no reason to reject either version, because y is a *mut and thus has no borrow/lifetime relation to the &mut that x is, from a compile-time/typesystem perspective.

vollbrecht•2h ago
Ah that make sense. Thanks for clarifying.
jcalvinowens•1h ago
> 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...).

ralfj•1h ago
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.

kookamamie•16m ago
Agreed about C's aliasing rules. Fortran had a better set of defaults.
Asooka•1h ago
While I can't name the product I work on, we also use -fno-strict-aliasing. The problem with these optimisations is that they can only be done safely if you can prove aliasing never happens, which is equivalent to solving the halting problem in C++. In Rust I suspect the stronger type system can actually prove that aliasing doesn't happen in select cases. In any case, I can always manually do the optimisations enabled by strict aliasing in hot code, but I can never undo a customer losing data due to miscompilation.
pornel•1h ago
> actually prove that aliasing doesn't happen in select cases

In the safe subset of Rust it's guaranteed in all cases. Even across libraries. Even in multi-threaded code.

steveklabnik•59m ago
While both involve aliasing, C's strict aliasing and Rust's aliasing are two different things. Rust pretty explicitly did not adopt the C style.

C's aliasing is based on type alone, hence its other name "type based alias analysis" or TBAA.

dzaima•58m ago
Rust's aliasing rules are very different from C's.

In C you have a nuclear `restrict` that in my experience does anything only when applied to function arguments across clang & gcc, and type-based aliasing which is both not a generally-usable thing (don't have infinite different copies of the int64_t type (and probably wouldn't want such either)), and annoying (forces using memcpy if you want to reinterpret to a different type).

Whereas with Rust references you have finely-bounded lifetimes and spans and mutability, and it doesn't actually care about the "physical" types, so it is possible to reinterpret memory as both `&mut i32`/`&i32` and `&mut i64`/`&i64` and switch between the two for the same memory, writing/reading halves of/multiple values by the most bog standard Rust safe reads & writes, as long as the unsafe abstraction never gives you overlapping `&mut` references at the same time.

jandrewrogers•9m ago
Strict aliasing rules are useful conditional on them being sufficiently expressive and sensible, otherwise they just create pointless headaches that require kludgy workarounds or they are just disabled altogether. I don't think there is much disagreement that C strict aliasing rules are pretty broken. There is no reason a language like Rust can't be designed with much more sensible strict aliasing rules. Even C++ has invested in providing paths to more flexibility around strict aliasing than C provides.

But like Linus, I've noticed it doesn't seem to make much difference outside of obvious narrow cases.

gavinhoward•54m ago
This looks excellent. I will probably implement this model for my own language.

When politicians gain power, their language becomes garbled

https://phys.org/news/2025-06-politicians-gain-power-language-garbled.html
1•PaulHoule•55s ago•0 comments

Belitsoft sees a rise in full-stack developer hiring in 2025 (UK, USA, Canada)

https://www.londondaily.news/belitsoft-sees-a-rise-in-full-stack-developer-hiring-in-2025-uk-usa-canada/
1•Aninay•3m ago•0 comments

Apple Now Wants to Buy Streaming Rights for Formula 1 Racing

https://www.macrumors.com/2025/07/09/apple-wants-to-buy-f1-streaming-rights/
1•mgh2•3m ago•0 comments

I got rid of all my Neovim plugins

https://yobibyte.github.io/vim.html
1•sharjeelsayed•4m ago•0 comments

Show HN: LLviM – A conversational coding plugin for Vim and Local LLMs

https://github.com/gkchestertron/LLviM
1•trs83•5m ago•0 comments

Section-174 is reversed: all US-based R&D expenses are now deductible

https://www.afternoon.co/blog/section-174-is-reversed
3•romanzubenko•5m ago•0 comments

Save Yourself Some Dough on Apple Kit and Make Me Rich on Amazon Prime Day

https://daringfireball.net/2025/07/make_me_rich_on_amazon_prime_day
1•Bogdanp•6m ago•0 comments

Nvidia becomes first company to be worth $4T

https://www.nbcnews.com/business/business-news/nvidia-becomes-first-company-worth-4-trillion-what-to-know-rcna217721
1•mgh2•6m ago•0 comments

Would You Like an IDOR With That? Leaking 64m McDonald's Job Applications

https://ian.sh/mcdonalds
1•samwcurry•8m ago•0 comments

Denmark's ambitious plan to boost plant-based foods

https://channels.ft.com/en/rethink/denmarks-ambitious-plan-to-boost-plant-based-foods/
1•miles•9m ago•0 comments

Mellow Drama: Turning Browsers into Request Brokers

https://secureannex.com/blog/mellow-drama/
1•wut42•11m ago•0 comments

Helix Parallelism: Sharding Strategies for Multi-Million-Token LLM Decoding

https://research.nvidia.com/publication/2025-07_helix-parallelism-rethinking-sharding-strategies-interactive-multi-million
2•h6d_100c•12m ago•0 comments

Study on the dynamics of an origami space plane during Earth atmospheric entry

https://www.sciencedirect.com/science/article/pii/S0094576525004047
1•gnabgib•12m ago•0 comments

Chalk – Metadata Code Tracking Made Easy

https://github.com/crashappsec/chalk
1•TheWiggles•17m ago•0 comments

We've got a surprise Pixel Drop for you (July 2025)

https://blog.google/products/pixel/pixel-drop-july-2025/
1•raybb•18m ago•0 comments

Apple says COO Jeff Williams will retire from company later this year

https://www.cnbc.com/2025/07/08/apple-says-coo-jeff-williams-handing-over-role-to-sabih-khan-this-month.html
2•amrrs•19m ago•0 comments

Biomni: A General-Purpose Biomedical AI Agent

https://github.com/snap-stanford/Biomni
6•GavCo•20m ago•0 comments

DRAM prices are about to skyrocket – DDR4 and GDDR6 prices could increase by 45%

https://www.tomshardware.com/pc-components/dram/dram-prices-are-about-to-skyrocket-ddr4-and-gddr6-among-formats-that-could-increase-in-price-by-up-to-45-percent
2•aieconosab•21m ago•0 comments

Driving Content Delivery Efficiency Through Classifying Cache Misses

https://netflixtechblog.com/driving-content-delivery-efficiency-through-classifying-cache-misses-ffcf08026b6c
2•GavCo•22m ago•0 comments

We asked 9 AI and agent builders about their top problems

https://unionailoop.substack.com/p/we-asked-9-ai-and-agent-builders
1•aitacobell•23m ago•0 comments

Let Kids Be Loud

https://www.afterbabel.com/p/let-kids-be-loud
2•trevin•23m ago•0 comments

From MIT, an instruction manual for turning research into startups

https://news.mit.edu/2025/from-mit-instruction-manual-for-turning-research-into-startups-0624
2•gnabgib•25m ago•1 comments

Perplexity Comet

https://comet.perplexity.ai/?a=b
16•birriel•26m ago•14 comments

Samsung Galaxy Z Fold7

https://www.samsung.com/us/smartphones/galaxy-z-fold7/
1•sahaskatta•26m ago•0 comments

Open-source bot blocker shields your site from pesky AI scrapers

https://www.zdnet.com/article/this-open-source-bot-blocker-shields-your-site-from-pesky-ai-scrapers-heres-how/
1•CrankyBear•26m ago•1 comments

Show HN: EgoExo Forge: Data and Utilities Needed for Ego and Exo Human Data

https://pablovela5620-egoexo-forge-viewer.hf.space
2•pablovelagomez•28m ago•0 comments

Google fails to dismiss wiretapping claims on SJ, settles with app users

2•1vuio0pswjnm7•28m ago•0 comments

Build visual AI workflows from a prompt – OCR, detection, editing and more

https://colab.research.google.com/github/vlm-run/vlmrun-cookbook/blob/main/notebooks/10_mcp_showcase.ipynb
4•fzysingularity•28m ago•2 comments

Have All the Planets Ever Aligned? The Closest We'll Get Is May 6, 2492

https://www.iflscience.com/have-all-the-planets-ever-aligned-the-closest-well-get-is-may-6-2492-77642
2•ilius2•29m ago•0 comments

Trump appointees stand to benefit from privatizing weather forecasts

https://www.yahoo.com/news/trump-appointees-ties-companies-stand-113810376.html
6•ivape•32m ago•0 comments