Design a language feature to solve Field Projections

[nikomatsakis]

Metadata
Point of contact	@BennoLossin
Team(s)	lang
Goal document	2025h2/field-projections

Summary

Figure out the best design for field projections. Update the existing Field Projections RFC or
author a new one and implement it for use in nightly via a lang experiment.

Tasks and status

• Design meeting 1 (lang )
  • Happened on 2025-08-13: Design meeting: Field projections lang-team#335
• Design meeting 2 (lang )
• Lang-team experiment (lang )
  • Approve the experiment
  • Tracking issue Tracking Issue for Field Projections rust#145383
  • merge FRTs Add field representing types rust#146307
• Author RFC (@BennoLossin)

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[BennoLossin]

Key Developments

• coordinating with #![feature(pin_ergonomics)] (Tracking issue for pin ergonomics rust#130494) to ensure compatibility between the two features (allow custom pin projections to be the same as the ones for &pin mut T)
• identified connection to auto reborrowing
  • Reborrow traits #399
  • Tracking Issue for Reborrow trait lang experiment rust#145612
• held a design meeting
  • very positive feedback from the language team
  • approved lang experiment
  • got a vibe check on design axioms
• created a new Zulip channel #t-lang/custom-refs for all new features needed to make custom references more similar to &T/&mut T such as field projections, auto reborrowing and more
• created the tracking issue for #![feature(field_projections)]
• opened Add field representing types rust#146307 to implement field representing types (FRTs) in the compiler

Next Steps

• Get Add field representing types rust#146307 reviewed & merged

Help Wanted

• When the PR for FRTs lands, try out the feature & provide feedback on FRTs
• if possible using the field-projection crate and provide feedback on projections

Internal Design Updates

Shared & Exclusive Projections

We want users to be able to have two different types of projections analogous to &T and &mut T. Each field can be projected independently and a single field can only be projected multiple times in a shared way. The current design uses two different traits to model this. The two traits are almost identical, except for their safety documentation.

We were thinking if it is possible to unify them into a single trait and have coercions similar to autoreborrowing that would allow the borrow checker to change the behavior depending on which type is projected.

Syntax

There are lots of different possibilities for which syntax we can choose, here are a couple options: @x->f/@mut x->f, @x.f/@mut x.f, x.@f/x.mut@f, x.ref.@f/x.@f. Also many alternatives for the sigils used: x@f, x~f, x.@.f.

We have yet to decide on a direction we want to go in. If we are able to merge the two project traits, we can also settle on a single syntax which would be great.

Splitting Projections into Containers & Pointers

There are two categories of projections: Containers and Pointers:

• Containers are types like MaybeUninit<T>, Cell<T>, UnsafeCell<T>, ManuallyDrop<T>. They are repr(transparent) and apply themselves to each field, so MaybeUninit<MyStruct> has a field of type MaybeUninit<MyField> (if MyStruct has a field of type MyField).
• Pointers are types like &T, &mut T, cell::Ref[Mut]<'_, T>, *const T/*mut T, NonNull<T>. They support projecting Pointer<'_, Struct> to Pointer<'_, Field>.

In the current design, these two classes of projections are unified by just implementing Pointer<'_, Container<Struct>> -> Pointer<'_, Container<Field>> manually for the common use-cases (for example &mut MaybeUninit<Struct> -> &mut MaybeUninit<Field>). However this means that things like &Cell<MaybeUninit<Struct>> doesn't have native projections unless we explicitly implement them.

We could try to go for a design that has two different ways to implement projections -- one for containers and one for pointers. But this has the following issues:

• there are two ways to implement projections, which means that some people will get confused which one they should use.
• making projections through multiple container types work out of the box is great, however this means that when defining a new container type and making it available for projections, one needs to consider all other container types and swear coherence with them. If we instead have an explicit way to opt in to projections through multiple container types, the implementer of that trait only has to reason about the types involved in that operation.
  • so to rephrase, the current design allows more container types that users actually use to be projected whereas the split design allows arbitrary nestings of container types to be projected while disallowing certain types to be considered container types.
• The same problem exists for allowing all container types to be projected by pointer types, if I define a new pointer type I again need to reason about all container types and if it's sound to project them.

We might be able to come up with a sensible definition of "container type" which then resolves these issues, but further investigation is required.

Projections for &Custom<U>

We want to be able to have both a blanket impl<T, F: Field<Base = T>> Project<F> for &T as well as allow people to have custom projections on &Custom<U>. The motivating example for custom projections is the Rust-for-Linux Mutex that wants these projections for safe RCU abstractions.

During the design meeting, it was suggested we could add a generic to Project that only the compiler is allowed to insert, this would allow disambiguation between the two impls. We have now found an alternative approach that requires less specific compiler magic:

• Add a new marker trait ProjectableBase that's implemented for all types by default.
• People can opt out of implementing it by writing impl !ProjectableBase for MyStruct; (needs negative impls for marker traits).
• We add where T: ProjectableBase to the impl Project for &T.
• The compiler needs to consider the negative impls in the overlap check for users to be able to write their own impl<U, F> Project<F> for &Custom<U> where ... (needs negative impl overlap reasoning)

We probably want negative impls for marker traits as well as improved overlap reasoning for different reasons too, so it is probably fine to depend on them here.

enum support

enum and union shouldn't be available for projections by default, take for example &Cell<Enum>, if we project to a variant, someone else could overwrite the value with a different variant, invalidating our &Cell<Field>. This also needs a new trait, probably AlwaysActiveField (needs more name bikeshedding, but too early for that) that marks fields in structs and tuples.

To properly project an enum, we need:

• a new CanProjectEnum (TBB) trait that provides a way to read the discriminant that's currently inhabiting the value.
  • it also needs to guarantee that the discriminant doesn't change while fields are being projected (this rules out implementing it for &Cell)
• a new match operator that will project all mentioned fields (for &Enum this already is the behavior for match)

Field Representing Types (FRTs)

While implementing rust-lang/rust#146307 we identified the following problems/design decisions:

• a FRT is considered local to the orphan check when each container base type involved in the field path is local or a tuple (see the top comment on the PR for more infos)
• FRTs cannot implement Drop
• the Field trait is not user-implementable
• types with fields that are dynamically sized don't have a statically known offset, which complicates the UnalignedField trait,

I decided to simplify the first implementation of FRTs and restrict them to sized structs and tuples. It also doesn't support packed structs. Future PRs will add support for enums, unions and packed structs as well as dynamically sized types.

[BennoLossin]

Decomposing Projections

A chained projection operation should naturally decompose, so foo.@bar.@baz should be the same as writing (foo.@bar).@baz. Until now, the different parenthesizing would have allowed different outcomes. This behavior is confusing and also makes many implementation details more complicated than they need to be.

Field Representing Types

Since projections now decompose, we have no need from a design perspective for multi-level FRTs. So field_of!(Foo, bar.baz) is no longer required to work. Thus we have decided to restrict FRTs to only a single field and get rid of the path. This simplifies the implementation in the compiler and also avoids certain difficult questions such as the locality of FRTs (if we had a path, we would have to walk the path and it is local, if all structs included in the path are local). Now with only a single field, the FRT is local if the struct is.

We also discovered that it is a good idea to make FRTs inhabited (they still are ZSTs), since then it allows the following pattern to work:

fn project_free_standing<F: Field>(_: Field, r: &F::Base) -> &F::Type { ... }

// can now call the function without turbofish:
let my_field = project_free_standing(field_of!(MyStruct, my_field), &my_struct);

FRTs via const Generics

We also spent some time thinking about const generics and FRTs on zulip:

• https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/const.20generics.3A.20implementing.20field.20representing.20types/with/544617587
• https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/field.20representing.20values.20.26.20.60Field.3Cconst.20F.3A.20.3F.3F.3F.3E.60.20trait/with/542855620

In short, this won't be happening any time soon. However, it could be a future implementation of the field_of! macro depending on how reflection through const generics evolves (but also only in the far-ish future).

[BennoLossin]

Single Project Operator & Trait via Exclusive Decay

It would be great if we only had to add a single operator and trait and could obtain the same features as we have with two. The current reason for having two operators is to allow both shared and exclusive projections. If we could have another operation that decays an exclusive reference (or custom, exclusive smart-pointer type) into a shared reference (or the custom, shared version of the smart pointer). This decay operation would need borrow checker support in order to have simultaneous projections of one field exclusively and another field shared (and possibly multiple times).

This goes into a similar direction as the reborrowing project goal #399, however, it needs extra borrow checker support.

fn add(x: cell::RefMut<'_, i32>, step: i32) {
    *x = *x + step;
}

struct Point {
    x: i32,
    y: i32,
}

fn example(p: cell::RefMut<'_, Point>) {
    let y: cell::Ref<'_, i32> = coerce_shared!(p.@y);
    let y2 = coerce_shared!(p.@y); // can project twice if both are coerced
    add(p.@x, *y);
    add(p.@x, *y2);
    assert_eq!(*y, *y2); // can still use them afterwards
}

Problems:

• explicit syntax is annoying for these "coercions", but
• we cannot make this implicit:
  • if this were an implicit operation, only the borrow checker would know when one had to coerce,
  • this operation is allowed to change the type,
  • this results in borrow check backfeeding into typecheck, which is not possible or at least extremely difficult

Syntax

Not much movement here, it depends on the question discussed in the previous section, since if we only have one operator, we could choose .@, -> or ~; if we have to have two, then we need additional syntax to differentiate them.

[BennoLossin]

Simplifying the Project trait

There have been some developments in pin ergonomics rust-lang/rust#130494: "alternative B" is now the main approach which means that Pin<&mut T> has linear projections, which means that it doesn't change its output type depending on the concrete field (really depending on the field, not only its type). So it falls into the general projection pattern Pin<&mut Struct> -> Pin<&mut Field> which means that Pin doesn't need any where clauses when implementing Project.

Additionally we have found out that RCU also doesn't need where clauses, as we can also make its projections linear by introducing a MutexRef<'_, T> smart pointer that always allows projections and only has special behavior for T = Rcu<U>. Discussed on zulip after this message.

For this reason we can get rid of the generic argument to Project and mandate that all types that support projections support them for all fields. So the new Project trait looks like this:

// still need a common super trait for `Project` & `ProjectMut`
pub trait Projectable {
    type Target: ?Sized;
}

pub unsafe trait Project: Projectable {
    type Output<F: Field<Base = Self::Target>>;

    unsafe fn project<F: Field<Base = Self::Target>>(
        this: *const Self,
    ) -> Self::Output<F>;
}

Are FRTs even necessary?

With this change we can also think about getting rid of FRTs entirely. For example we could have the following Project trait:

pub unsafe trait Project: Projectable {
    type Output<F>;

    unsafe fn project<const OFFSET: usize, F>(
        this: *const Self,
    ) -> Self::Output<F>;
}

There are other applications for FRTs that are very useful for Rust-for-Linux. For example, storing field information for intrusive data structures directly in that structure as a generic.

Detailed Example for non-projection use-case for FRTs

More concretely, in the kernel there are workqueues that allow you to run code in parallel to the currently running thread. In order to insert an item into a workqueue, an intrusive linked list is used. However, we need to be able to insert the same item into multiple lists. This is done by storing multiple instances of the Work struct. Its definition is:

pub struct Work<T, const ID: u64> { ... }

Where the ID generic must be unique inside of the struct.

struct MyDriver {
    data: Arc<MyData>,
    main_work: Work<Self, 0>,
    aux_work: Work<Self, 1>,
    // more fields ...
}

// Then you call a macro to implement the unsafe `HasWork` trait safely.
// It asserts that there is a field of type `Work<MyDriver, 0>` at the given field
// (and also exposes its offset).
impl_has_work!(impl HasWork<MyDriver, 0> for MyDriver { self.main_work });
impl_has_work!(impl HasWork<MyDriver, 1> for MyDriver { self.aux_work });

// Then you implement `WorkItem` twice:

impl WorkItem<0> for MyDriver {
    type Pointer = Arc<Self>;
    
    fn run(this: Self::Pointer) {
        println!("doing the main work here");
    }
}

impl WorkItem<1> for MyDriver {
    type Pointer = Arc<Self>;
    
    fn run(this: Self::Pointer) {
        println!("doing the aux work here");
    }
}

// And finally you can call `enqueue` on a `Queue`:

let my_driver = Arc::new(MyDriver::new());
let queue: &'static Queue = kernel::workqueue::system_highpri();
queue.enqueue::<_, 0>(my_driver.clone()).expect("my_driver is not yet enqueued for id 0");

// there are different queues
let queue = kernel::workqueue::system_long();
queue.enqueue::<_, 1>(my_driver.clone()).expect("my_driver is not yet enqueued for id 1");

// cannot insert multiple times:
assert!(queue.enqueue::<_, 1>(my_driver.clone()).is_err());

FRTs could be used instead of this id, making the definition be Work<F: Field> (also merging the T parameter).

struct MyDriver {
    data: Arc<MyData>,
    main_work: Work<field_of!(Self, main_work)>,
    aux_work: Work<field_of!(Self, aux_work)>,
    // more fields ...
}

impl WorkItem<field_of!(MyDriver, main_work)> for MyDriver {
    type Pointer = Arc<Self>;
    
    fn run(this: Self::Pointer) {
        println!("doing the main work here");
    }
}

impl WorkItem<field_of!(MyDriver, aux_work)> for MyDriver {
    type Pointer = Arc<Self>;
    
    fn run(this: Self::Pointer) {
        println!("doing the aux work here");
    }
}

let my_driver = Arc::new(MyDriver::new());
let queue: &'static Queue = kernel::workqueue::system_highpri();
queue
    .enqueue(my_driver.clone(), field_of!(MyDriver, main_work))
    //                          ^ using Gary's idea to avoid turbofish
    .expect("my_driver is not yet enqueued for main_work");

let queue = kernel::workqueue::system_long();
queue
    .enqueue(my_driver.clone(), field_of!(MyDriver, aux_work))
    .expect("my_driver is not yet enqueued for aux_work");

assert!(queue.enqueue(my_driver.clone(), field_of!(MyDriver, aux_work)).is_err());

This makes it overall a lot more readable (by providing sensible names instead of magic numbers), and maintainable (we can add a new variant without worrying about which IDs are unused). It also avoids the unsafe HasWork trait and the need to write the impl_has_work! macro for each Work field.

I still think that having FRTs is going to be the right call for field projections as well, so I'm going to keep their experiment going. However, we should fully explore their necessity and rationale for a future RFC.

[BennoLossin]

Making Project::project safe

In the current proposal the Project::project function is unsafe, because it takes a raw pointer as an argument. This is pretty unusual for an operator trait (it would be the first). @tmandry thought about a way of making it safe by introducing "partial struct types". This new type is spelled Struct.F where F is an FRT of that struct. It's like Struct, but with the restriction that only the field represented by F can be accessed. So for example &Struct.F would point to Struct, but only allow one to read that single field. This way we could design the Project trait in a safe manner:

// governs conversion of `Self` to `Narrowed<F>` & replaces Projectable
pub unsafe trait NarrowPointee {
    type Target;

    type Narrowed<F: Field<Base = Self::Target>>;
}

pub trait Project: NarrowPointee {
    type Output<F: Field<Base = Self::Type>>;

    fn project(narrowed: Self::Narrowed<F>) -> Self::Output<F>;
}

The NarrowPointee trait allows a type to declare that it supports conversions of its Target type to Target.F. For example, we would implement it for RefMut like this:

unsafe impl<'a, T> NarrowPointee for RefMut<'a, T> {
    type Target = T;
    type Narrowed<F: Field<Base = T>> = RefMut<'a, T.F>;
}

Then we can make the narrowing a builtin operation in the compiler that gets prepended on the actual coercion operation.

However, this "partial struct type" has a fatal flaw that @oli-obk found (edit by oli: it was actually boxy who found it): it conflicts with mem::swap, if Struct.F has the same layout as Struct, then writing to such a variable will overwrite all bytes, thus also overwriting field that aren't F. Even if we make an exception for these types and moves/copies, this wouldn't work, as a user today can rely on the fact that they write size_of::<T>() bytes to a *mut T and thus have a valid value of that type at that location. @tmandry suggested we make it !Sized and even !MetaSized to prevent overwriting values of that type (maybe the Overwrite trait could come in handy here as well). But this might make "partial struct types" too weak to be truly useful. Additionally this poses many more questions that we haven't yet tackled.

[BennoLossin]

TL;DR:

There have been lots of internal developments since the last update:

• field representing types and chained projections have received a fundamental overhaul: disallowing field paths and requiring projections to decompose. Additionally we explored how const generics could emulate FRTs.
• we discussed a potential solution to having only a single project operator & trait through a decay operation with special borrow checker treatement.
• we were able to further simplify the project trait moving the generic argument of the represented field to the project function. We also discovered the possibility that FRTs are not fundamentally necessary for field projections -- however, they are still very useful in other applications and my gut feeling is that they are also right for field projections. So we will continue our experiment with them.
• we talked about making Project::project be a safe function by introducing a new kind of type.

Next Steps:

• we're still planning to merge Add field representing types rust#146307, after I have updated it with the new FRT logic and it has been reviewed
• once that PR lands, I plan to update the library experiment to use the experimental FRTs
• then the testing using that library can begin in the Linux kernel and other projects (this is where anyone interested in trying field projections can help out!)

[BennoLossin]

Moving Projections and &own

Moving projections are a third kind of projection that already exists in Rust today for Box as well as any local variable holding a struct. While we won't be including it in an MVP, we still want to make sure that we can extend the language with moving projections. Here is an example with Box:

fn destructure_box(mut b: Box<Struct>) -> Box<Struct> {
    let f1 = b.f1;
    b.f1 = F1::new();
    b
}

This projection moves the field out of the box, invalidating it in the process. To make it valid again, a new value has to be moved in for that field. Alternatively, the partially valid box can be dropped, this will drop all other fields of Struct and then deallocate the Box. Note that this last property is implemented by compiler magic today and moving projections would allow this special behavior for Box to be a library implementation instead.

To make this kind of projection available for all types, we can make it a proper operation by adding this trait:

pub unsafe trait ProjectMove: Projectable {
    type OutputMove<'a, F: Field<Base = Self::Target>>;
    
    unsafe fn project_move<'a, F: Field<Base = Self::Target>>(
        this: *mut Self,
    ) -> Self::OutputMove<'a, F>;
    
    unsafe fn drop_husk(husk: *mut Self);
}

Importantly, we also need a drop_husk function which is responsible for cleaning up the "husk" that remains when all fields have been move-projected. In the case of Box, it deallocates the memory. So for Box we could implement this trait like this:

impl<T> ProjectMove for Box<T> {
    type OutputMove<'a, F: Field<Base = T>> = F::Type;

    unsafe fn project_move<'a, F: Field<Base = T>>(
        this: *mut Self,
    ) -> F::Type {
        let ptr = unsafe { (*this).0.pointer.as_ptr() };
        ptr::read(unsafe {
            <*const T as Project>::project::<'a, F>(&raw const ptr)
        })
    }

    unsafe fn drop_husk(husk: *mut Self) {
        // this is exactly the code run by `Box::drop` today, as the compiler
        // drops the `T` before `Box::drop` is run.
        let ptr = (*husk).0;
        unsafe {
            let layout = Layout::for_value_raw(ptr.as_ptr());
            if layout.size() != 0 {
                (*husk).1.deallocate(From::from(ptr.cast()), layout);
            }
        }
    }
}

To support moving back into a value we have two options:

1. Add a ProjectMoveBack trait that declares an operation which accepts a value that is moved back into the projected one, or
2. Add &own references.

Until now, we have explored the second option, because there are lot's of other applications for &own.

&own References

A small interlude on &own references.

An &'a own T is a special kind of exclusive reference that owns the value it points to. This means that if you drop an &own T, you also drop the pointee. You can obtain an &own T by constructing it directly to local variable &own my_local or by deriving it from an existing &own via field projections. Smart pointers generally also allow creating &own T from &own SmartPtr<T>.

One important difference to &mut T is that &own is not only temporally unique (i.e. there are no other references to that value not derived from it) but also unique for that value. In other words, one can create at most one &own T to a local variable.

let mut val = Struct { ... };
let x = &own val; //~ HELP: ownership transferred here
drop(x);
let y = &own val; //~ ERROR: cannot own `val` twice

Since the drop(x) statement drops val, the borrow checker must disallow any future access. However, we are allowed to move a value back into the memory of val:

let mut val = Struct { ... };
let x = &own val;
drop(x);
val = Struct { ... };
let y = &own val;

The lifetime 'a in &'a own T is that of the backing memory. It means that when 'a expires, the memory also is no longer valid (or rather it cannot be proven that it is valid after 'a). For this reason an &'a own T has to be dropped (or forgotten) before 'a expires (since after that it cannot be dropped any more).

&own T itself supports moving projections (another indicator that having them is a good idea). However only for types that don't implement Drop (similar to normal struct destructuring -- there are also talks about lifting this requirement, but no new issues arise from projecting &own).

&own and pinning

To make &pin own T with !(T: Unpin) sound in the face of panics, we have to add drop flags or have unforgettable types. We explored a design using drop flags below; there are separate efforts to experimenting with a Leak/Forget trait ongoing, I think it might be a better solution than drop flags at least for &own.

We need drop flags to ensure the drop guarantee of pinned values. The drop flag will be stored when the original &own is created and it will live on the stack of the function that created it. They are needed for the following scenario:

fn foo() {
    let x = Struct { ... };
    bar(&pin own x);
}

fn bar(x: &pin own Struct) {
    if random() {
        std::mem::forget(x);
    }
    if random() {
        panic!()
    }
}

Since x is pinned on the stack, it needs to be dropped before foo returns (even if it unwinds). When bar forgets the owned reference, the destructor is not run, if it now panics, the destructor needs to be run in foo. But since it gave away ownership of x to bar, it is possible that bar already dropped x (this is the case when the first random() call returns false). To keep track of this, we need a drop flag in the stack frame of foo that gets set to true when x is dropped.

There are several issues with drop flags:

• we can't have &'static own T pointing to non-static values (for example coming from a Box::leak_owned function).
• field projections complicate things: if we project to a field, then we could possibly forget one field, but drop another
  • solution: just store drop flags not only for the whole struct, but also all transitive fields that implement Drop
• there is different behavior between &own T and &pin own T, the former can be forgotten and the destructor will not run, the latter can also be forgotten, but the destructor runs regardless.

This last point convinces me that we actually want &pin own T: !Leak when T: !Leak; but IIUC, that wouldn't prevent the following code from working:

fn main() { 
    let x = Struct { ... };
    let x = &pin own x;
    Box::leak(Box::new(x));
}

DerefMove

The DerefMove operation & trait is something that has been discussed in the past (I haven't dug up any discussions on it though). It is the analogous operation of &own to Deref. We need to figure out the hierarchy wrt. Deref and DerefMut, but ignoring that issue for the moment, here is how DerefMove would look like:

trait DerefMove: DropHusk {
    trait Target: ?Sized;

    fn deref_move(&own self) -> &own Self::Target;
}

Note the super trait requirement DropHusk -- it provides a special drop operation for Self when the &own Self::Target reference has been dropped. Box<T> for example would deallocate the backing memory via DropHusk. Its definition looks like this:

pub unsafe trait DropHusk {
    unsafe fn drop_husk(husk: *mut Self);
}

We would of course also use this trait for ProjectMove. Implementing DropHusk on its own does nothing; implementing DerefMove or ProjectMove will make the compiler call drop_husk instead of Drop::drop when the value goes out of scope after it has been projected or DerefMove::deref_move has been called.

We observed that DerefMove is a lot more restrictive in its usability than Deref--- and we need projections to make it actually useful in the common case. The reason for this is that &own can only be created once, but one would like to be able to create it once per field (which is exactly what moving projections allow). Consider this example:

let b = Box::new(Struct { ... });
let field1 = &own b.field1; // desugars to `DerefMove::deref_move`
let field2 = &own b.field2; //~ ERROR: cannot own `b` twice

The "cannot own `b` twice error comes from the way the deref desugaring works:

let b = Box::new(Struct { ... });
let field1 = &own DerefMove::deref_move(&own b).f1;
let field2 = &own DerefMove::deref_move(&own b).f2;
//                                       ^^^ ERROR: cannot own `b` twice

Now it's clear that we're trying to create two &own to the same value and that can't work (the issue also arises for &mut, but that already is covered by ProjectExclusive).

We can write this instead:

let b = Box::new(Struct { ... });
let b = &own b;
let field1 = &own b.field1;
let field2 = &own b.field2;

But that's cumbersome.

We also note that ProjectMove is the correct projection for ArcRef, as it avoids any additional refcount updates. We can rely on the ergonomic refcounting proposal to provide ergonomic ways to clone the value & perform more projections.

[BennoLossin]

Having a single Project trait

The definition of the now 3 Project* traits are 100% verbatim the same (modulo renaming of course), so we spent some time trying to unify them into a single trait. While we cannot get rid of having to have three traits, we can merge them into a single one by adding a generic:

#[sealed]
pub trait ProjectKind {
    type Ptr<T: ?Sized>;
}

pub enum Shared {}
pub enum Exclusive {}

impl ProjectKind for Shared {
    type Ptr<T: ?Sized> = *const T;
}

impl ProjectKind for Exclusive {
    type Ptr<T: ?Sized> = *mut T;
}

pub trait Projectable {
    type Target;
}

pub unsafe trait Project<Kind: ProjectKind>: Projectable {
    type Output<'a, F: Field<Base = Self::Target>>;

    unsafe fn project<'a, F: Field<Base = Self::Target>>(
        this: Kind::Ptr<Self>,
    ) -> Self::Output<'a, F>;
}

We would need some more compiler magic to ensure that nobody implements this trait generically, so impl<K> Project<K> for MyType, to keep our approach extendible (this could be an attribute if it is also useful in other cases #[rustc_deny_generic_impls]).

The benefit of merging the definitions is that we only have one single trait that we need to document and we could also add documentation on the ProjectKind types. There are also ergonomic downsides, for example all output types are now called Output and thus need to be fully qualified if multiple projection impls exist (<MyType as Project<Exclusive>>::Output<'_, F> vs MyType::OutputExclusive<'_, F>).

To make this proposal compatible with moving projections, we also either need more compiler magic to ensure that if Kind = Move we require Self: DropHusk. Or we could use associated traits and add one to ProjectKind that's then used in Project (Kind = Shared would then set this to Pointee).

This approach also makes me think a bit more about the syntax, if we discover more projections in the future, it might make sense to go for an extensible approach, like @keyword expr{->,.@,.,~}ident (so for example @move x->y or @mut x.y).