"Mutability polymorphism"

[glaebhoerl]

It would be desirable to, at some point, grow the ability to abstract over the "mutability" of reference types. Currently, it is frequently the case that one must write separate "getter" methods for shared & and unique &mut references, even though the bodies of these methods are exactly the same. This is especially bothersome when those method bodies are nontrivial.

See an earlier discussion on reddit here.

Ideas for accomplishing this could potentially be borrowed from the research mentioned in this presentation, as well as from the Disciple language (a language with region types, effect types (e.g. mutation involving a region), and polymorphism over both).

This could also potentially allow the Fn/FnMut/FnOnce, Deref/DerefMut, Index/IndexMut, and so forth hierarchies to be collapsed into single traits parameterized over capabilities / effects / constraints (whatever we choose to call them).

[blaenk]

Yeah, this would be very useful I think.

[thehydroimpulse]

/cc me

[reem]

It would be even better if we could abstract over ownership status, i.e. we could collapse Trait[Mut|Move]? into just Trait.

[brendanzab]

This would be great. Do you have any thoughts on how this could be added in a backwards compatible way in the future?

[reem]

Not really. I think this deserves consideration pre-1.0 because it would collapse and change traits which are lang items, such as the Deref, Fn and Index families. Code that implemented those traits would be broken.

Parametrizing over mutability is much easier than parametrizing over ownership, since you can just say "if you have &m? T you can only treat it like &T", but the story with owned? T becomes trickier.*

* note all syntax is super hypothetical

[glaebhoerl]

Yeah, figuring out how to abstract over out and move is much less obvious than mut and shared. Possibly we would have to take a capability-based perspective on it (see that presentation, particularly the part about strong updates), i.e. currently Rust's references are pointers bundled together with the capabilities to access them; maybe taking them separately and, possibly, having traits on capabilities or something might lead us in the right direction... but this is extremely hazy and hand-wavy for now.

[Gankra]

@reem I don't think it's as easy as that. &T is often less restrictive, in that much more general code structures are valid with & and than &mut. You can make multiple &'s, and &mut's often necessitate temporary wrangling to appease borrowck (although this may simply be a SESE artifact).

You would have to assume that your ptrs are &mut's in some regards, and &'s in others. Of course, in a hypothetical polymorphic mutability world many of the restrictions that & provides would be swept away by virtue of presumably all getters being polymorphic and "just working".

[crlf0710]

This can be implemented with GAT, as type family pointers.

[mrahhal]

There hasn't been any activity on this for a long time. I've been thinking about this a lot for the past few days, didn't know there's an rfc for it. It seems there's just not enough interest in this?
I'm a new user of Rust and this has been one of the major pain points so far. (Simple use case is writing a visitor pattern that needs to be either & or &mut, with the exact same code otherwise. Currently trying to duplicate this using a proc macro)

[dullbananas]

This could be done with a &mut:M &:M syntax where M is a constant boolean

Example:

struct Thing(u8);

impl Thing {
    fn get_inner<const M: bool>(&:M self) -> &:M u8 {
        &:M self.0
    }
}

I can't believe there hasn't been a proposed syntax for 8 years!

This could be done with a &mut:M syntax where M is a constant boolean

I don't believe that syntax is the real blocker here. Although, what is the blocker? Interest?