Rust’s view types experiment aims for safer, more flexible field borrowing

Rust’s next ergonomics fight is about field borrowing, not syntax candy

The practical promise of `view_types` is easy to understand: let one function borrow just the fields it needs, while the rest of the struct stays usable. That sounds small until you hit the usual Rust pain points, where a perfectly normal data structure gets dragged through clones, wrapper types, or awkward reorganization just to satisfy the borrow checker.

That is why this experiment matters. The goal is not to weaken Rust’s safety model, but to make disjoint borrowing and fine-grained field access feel like first-class language features instead of a workaround puzzle. The tracking issue for rust-lang/rust#155938 makes that intent explicit: it wants the borrow checker to reason about borrows across function calls by giving the language a way to express which fields a function actually uses.

What `view_types` is trying to unlock

The headline use case is partial field borrowing. In plain terms, `view_types` is meant to let you borrow one field mutably and another field separately, without the compiler treating the whole struct as one inseparable block. The tracking issue’s example shows exactly the kind of payoff Rust programmers have wanted for years: a call shaped like `bar(&mut foo, &mut foo)` where one borrow reaches field `a` and the other reaches field `b`.

That matters because so much everyday Rust code runs into the same wall. You want to pass a struct into a helper, but the helper only needs `foo.left` and `foo.right`, not the entire owner. Today, that often means reshaping the data, splitting it manually, or inventing a wrapper type just to satisfy the checker. If `view_types` lands in a usable form, the language starts doing more of that accounting for you.

The stronger version of the idea goes even further. The notes around the experiment explicitly raise the possibility of extending views beyond references to owned values as well. That is the interesting part for builder patterns and partially initialized data structures, because it points toward type-checked staged construction without the usual generic-state boilerplate.

Why Rust users should care even if this is still experimental

This is not niche compiler gossip. It is the kind of change that alters how you write ordinary code when the borrow checker is in the way. If Rust can represent “I only need these fields” directly in the type system, then a lot of day-to-day friction starts to disappear.

The current pain points are familiar:

• cloning a value just to satisfy a helper
• boxing or wrapping data to break borrow conflicts
• splitting structs into smaller structs before you really want to
• adding generic-state machinery to model a simple staged builder
• backing away from a clean API because the borrow checker cannot see the subset you intended

That last point is the real ecosystem-wide consequence. Once a language feature starts making those compromises unnecessary, it affects API design across crates. It changes what people consider a “nice” Rust interface, because the compiler stops forcing so many ugly detours.

Where the experiment stands right now

S sha’s blog post, “One week of view_types,” shows just how early this is. After about a week of work on the feature, the author said there was not yet a fixed opinion on the ideal syntax. That is a useful signal: this is an active language experiment, not a polished proposal waiting for release.

The current experiment is guarded by `#![feature(view_types)]`, and the unstable book ties the feature directly to tracking issue #155938. The issue also draws some sharp boundaries around what is not being tackled yet. Using view types on `pub` or `pub(...)` functions is a hard error today. View groups are not considered yet, and interaction with pattern types is not considered yet either.

The syntax itself is also explicitly provisional. The tracking issue says it will certainly change during the experiment. That is the sort of line you want to see when a feature is still finding its shape, because it tells you the real work is in the language design, not just the implementation.

How this connects to Rust’s long-running borrow checker work

If this sounds familiar, that is because Rust has been circling this problem for a long time. The 2017 non-lexical lifetimes RFC framed borrow-checker improvements as a way to eliminate many of the small, local code changes developers used to need just to make the checker happy. `view_types` feels like a continuation of that same project, only aimed at a more stubborn limitation.

Rust Internals discussions in 2023 made the complaint even more direct: one of the borrow checker’s major limitations is that you cannot naturally create a reference that borrows only a subset of a type, in a way that lets non-overlapping subsets coexist without conflict. The same discussions treated a language-level solution as something long desired, not speculative wishful thinking.

That history matters because it shows the appetite is real. This is not a one-off ergonomic tweak. It is part of a persistent line of work aimed at narrowing the gap between what Rust can prove and what developers already know is safe in their code.

The broader roadmap points in the same direction

The 2026 Rust project goals include a `field-projections` effort, and that makes `view_types` feel less isolated than it might at first glance. That goal is about accessing fields through smart pointers and pinned references, not just plain `&` and `&mut`. In other words, the ecosystem is still pushing toward more precise, more expressive field access at the language level.

Taken together, `view_types` and `field-projections` suggest a broader trend: Rust is still trying to teach the borrow checker to understand smaller slices of reality. That is not flashy in the way a new keyword is flashy, but it is exactly the kind of change that removes friction from real codebases.

What to watch next

The immediate question is not whether `view_types` is perfect. It is whether the feature can keep moving toward a syntax and semantics that feel natural enough to use in real APIs. The experiments to watch are the obvious ones:

• whether the syntax settles on something readable and unsurprising
• whether the feature stays limited to references or expands to owned values
• whether public API support becomes possible later
• whether pattern types and view groups eventually enter the picture
• whether the compiler can reliably prove the same disjoint borrowing that developers already expect

The interesting part is that the target is not theoretical elegance. It is removing the everyday borrow-checker tax that still pushes Rust users into cloning, boxing, and reshaping data. If `view_types` keeps advancing, it could become one of those rare language changes that feels invisible in the best possible way: code just gets easier to write, and the safety model stays intact.