rust-lang / rust-lang/rust

Tracking Issue for Field Projections

Open
#145,383 2 comments 12 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

B-experimental C-tracking-issue F-field_projections T-lang
Dominant language
Rust
Stars
119k
Forks
16.1k
PR metrics pending

Description

This is a tracking issue for work on Field Projections.
The feature gate for the issue is #![feature(field_projections)].

This is a lang experiment at the moment and the feature is subject to change substantially over time.

We have an active project goal for this effort: https://github.com/rust-lang/rust-project-goals/issues/390

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

  • Approve as lang experiment

  • Hold a second design, notes from 2026-04-01

  • a-mir-formality: create a formal model of the borrow checker changes

    • familiarization & experimentation
      • do small experiments using the traits from the borrow checker
      • add our traits to the model
    • add lang-item crate https://github.com/rust-lang/a-mir-formality/pull/258
    • wait for Niko's new expression based syntax
    • Copy traits to new syntax https://github.com/rust-lang/a-mir-formality/pull/306
    • Integrate HasPlace with place expressions and projections
    • Integrate PlaceRead into the borrow checker (for Copy targets only)
    • Integrate PlaceWrite, PlaceDrop, DropHusk and PlaceRead (also for !Copy) into the borrow checker
    • Integrate PlaceBorrow into the borrow checker
    • Refine & Explore Model
      • Comprehensive test-suite
      • Ensure functionality of common patterns
    • Author document for explaining the model

  • Implementation: implement a compiler experiment

  • Experimentation: stress-test the experiment in real code

    • Questions to resolve by this experiment:
      • How much new syntax do we even need?
      • How bad is the ambiguity when making @place be inferred?
      • What effects does this have on SemVer in std & in general?
    • Linux Kernel
      • replace Gary's pointer projection infrastructure
      • Untrusted<T>
      • SeqLockRef<'_, T>
      • MutexGuard<'_ ,T>
      • Mutex<T> -> Rcu<U>
      • Arc<T>
      • Box<T>
      • ArcBorrow<'_, T>
    • Standard Library
      • MappedMutexGuard<'_, T>
      • UnsafeCell<T>
      • Cell<T>
      • ManuallyDrop<T>
      • MaybeUninit<T>
      • *const T & *mut T
      • NonNull<T>
      • Box<T>
      • Arc<T>
      • Rc<T>
      • &[mut] T
      • coordinate with t-libs-api on the creation of:
        • ArcRef<T> & UniqueArcRef<T>
        • ArcBorrow<'_, T>
        • ArcBox<T> (?)
        • WrappingPtr<T>
        • MutexGuardRef<'_, T>
        • MutexRef<'_, T>
        • Own<'_, T> (aka &own T)
      • ArcRef<T> & UniqueArcRef<T>
      • ArcBorrow<'_, T>
      • ArcBox<T> (?)
      • WrappingPtr<T>
      • cell::Ref[Mut]<'_, T>
      • MutexGuardRef<'_, T>
      • MutexRef<'_, T>
      • {btree_map,hash_map}::Entry @joshtriplett
    • pyo3 @davidhewitt
      • PyRef[Mut]<'_, T>
    • crubit @tmandry

  • User Research

    • What is the best name for HasPlace? Some good candidates are Place and Derefable.
    • How should the borrowing syntax look like? What's the best for the 95% use-case and what do users understand best?
Unresolved Questions
  • Should FRTs be provably (un)inhabited?
    Making them inhabited would allow APIs to take their value to reduce the amount of turbo-fish syntax in code my_fun(field_of!(Struct, field)) instead of my_fun::<field_of!(Struct, field)>(). There currently is no known advantage for provably uninhabited FRTs.
    • Resolved: they should be inhabited ZSTs to allow reducing the amount of turbofish syntax required to use them.
Implementation history

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source file or test is named. Start with the field_projections feature gate, the unchecked implementation checklist, and linked work in rust and a-mir-formality; a contribution is done when one specific checklist item is completed with its relevant implementation or design work and the tracking issue is updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.