TL;DR
A recent writeup maps a set of proposed reference kinds and summarizes their interactions with three tables showing reborrows, live-loan restrictions, and post-expiry effects. The proposals include owning (&own), uninitialized (&uninit) and pinning variants (&pin, &pin mut, &pin own), with implications for initialization, moves and drop behavior.
What happened
The author collected a set of proposals and encoded their interactions in three compact tables that describe (1) how one can reborrow from a given reference, (2) what operations remain possible on a place while a particular loan is live, and (3) what becomes possible after that loan has expired. The note clarifies terminology: a "place" denotes a memory location like x or x.field; taking a borrow produces a loan that records the place and the reference kind; a loan is considered live while its lifetime appears in some type. The writeup introduces speculative reference kinds: &own (an owning borrow that behaves like Box for dropping and permits moving out), &uninit (a borrow to an allocated but uninitialized slot that only permits writes until initialized), and pinning variants that attach a pinning requirement preventing moves or deallocation that would violate drop invariants. The document highlights interactions such as &own and &uninit leaving the place uninitialized at expiry, and notes some nuances (for example, reborrowing after writes and pin semantics) are not fully captured by the tables.
Why it matters
- Gives a systematic framework that could let the borrow checker reason about more than just shared vs mutable borrows.
- New reference kinds like &own and &uninit open API patterns for in-place initialization and owned-by-reference iteration (examples include pop_own and drain_own on Vec).
- Pinning variants encode drop/move constraints that matter for async code and other scenarios that rely on stable addresses and drop invariants.
- Understanding post-expiry semantics (e.g., places becoming uninitialized) affects safety reasoning and reuse of memory locations.
Key facts
- A "place" means a memory location expressed by things like x, *x, or x.field.
- Taking a borrow produces a loan; the loan is live while the borrow's lifetime appears in types and restricts operations on the place.
- Three tables in the source show: allowed reborrows from each reference kind, permitted operations while a loan is live, and permitted operations after a loan has expired.
- &own T is an owning borrow that drops the contained value when it itself is dropped and allows moving the T out of the reference.
- &uninit T denotes an allocated but not-yet-initialized location; with an &uninit one may only write to initialize it before reborrowing into other forms.
- &own and &uninit both cause the original place to be considered uninitialized when their borrows expire.
- Pinning references (&pin, &pin mut, &pin own) add a pinning requirement that forbids moving the value out or deallocating the place without running Drop; this restriction can persist after the borrow expires.
- &pin mut corresponds to today's Pin<&mut T> and is important for async code; &pin own and other pin variants are proposed extensions.
- The author notes the proposals are speculative and that some behaviors (e.g., reborrowing changes after writes, removal of pinning on drop) are more nuanced than the tables show.
What to watch next
- Whether these proposed reference kinds (&own, &uninit, &pin own, etc.) will be adopted into Rust's type system — not confirmed in the source.
- How the borrow checker implementation would encode these rules and what the migration path or backward-compatibility considerations would be — not confirmed in the source.
- Detailed semantics for edge cases, such as using &own to prove initialization to the borrow checker or precise interactions across function boundaries — not confirmed in the source.
Quick glossary
- place: A memory location described by an expression such as x, *x, or x.field.
- loan: A record created when taking a borrow; it remembers the place and reference kind and remains live while its lifetime occurs in types.
- reborrow: Creating a new borrow from an existing reference (for example, deriving &mut from &own), subject to the allowed conversions.
- pinning: A restriction that prevents moving or deallocating a value in ways that would violate drop invariants, often used to ensure stable addresses.
- &uninit: A borrow that refers to an allocated but uninitialized location; the primary permitted action is writing to initialize it.
Reader FAQ
What is &own and how does it differ from Box?
&own is an owning borrow that is responsible for dropping the contained value, like Box, but it does not imply control over allocation of the storage.
What can you do with &uninit?
&uninit points to allocated but uninitialized memory; the documented permitted operation is writing into it to initialize the value, after which it can be reborrowed.
Do pinning borrows persist their restrictions after they expire?
Yes — the writeup states pinning requirements forbid moving or deallocating the place without running Drop, and that restriction can remain after the borrow expires.
Will these changes land in Rust soon?
not confirmed in the source
The Algebra of Loans in Rust Dec 21, 2025 The heart of Rust borrow-checking is this: when a borrow is taken, and until it expires, access to the borrowed place…
Sources
- The Algebra of Loans in Rust
- Understanding Ownership and Borrowing in Rust
- The intuition behind Rust's borrowing rules and ownership
- References and Borrowing – The Rust Programming …
Related posts
- Geometric Algorithms for Translucency Sorting in Minecraft (PDF)
- Ultimate Linux: Building a Minimal Linux Userspace in Pure JavaScript
- Maybe Our Default Consumption Settings Are Set Far Too High Today