Skip to content

Tracking Issue for Field Projections #145383

@BennoLossin

Description

@BennoLossin

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: rust-lang/rust-project-goals#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

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

    • familiarization & experimentation
      • add our traits to the model
      • do small experiments using the traits from the borrow checker
    • wait for Niko's new expression based syntax
    • Copy traits to new syntax
    • 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

    • 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

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-field_projections`#![feature(field_projections)]`T-langRelevant to the language team

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    Exploration

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions