# Rust 2030 Christmas list: Inout methods

**URL:** <https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944>\
**Category:** language design\
**Created:** [January 10, 2022, 4:46pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944 "2022-01-10T16:46:40Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![PoignardAzur](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/poignardazur/32/6464_2.png) [@PoignardAzur](https://internals.rust-lang.org/u/PoignardAzur)\
**Post date:** [January 10, 2022, 4:46pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/1 "2022-01-10T16:46:40Z")

</div>

> **[Rust 2030 Christmas list: Inout methods](https://poignardazur.github.io/2022/01/05/rust-wishlist-inout-syntax/)**
>
> This is the third entry on my Christmas list for Rust 2030.

[Discussion on r/rust](https://www.reddit.com/r/rust/comments/s0ocgf/rust_2030_christmas_list_inout_methods/)

---

<div class="post-metadata">

**Author:** ![H2CO3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/h2co3/32/2849_2.png) [@H2CO3](https://internals.rust-lang.org/u/H2CO3)\
**Post date:** [January 10, 2022, 5:39pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/2 "2022-01-10T17:39:26Z")

</div>

From the post:

> my personal view is that if you’re only duplicating one or two line, adding abstraction to remove the duplication isn’t worth it

But then what do you justify this kind of feature with? Apart from trivial getter/setters (which are non-idiomatic and rare in the first place) and the 3 standard ref-to-ref conversions (`AsRef`, `Borrow` and `Deref`), there doesn't seem to be much space for methods that may be either mutable or immutable _and_ share the same implementation. Mutable references are different enough qualitatively, in their nature, that allowing mutation vs. allowing sharing doesn't usually warrant copy-pasting any non-trivial implementations. And adding a separate language feature for them seems like an overkill.

> How would they transition to inout mutability?
> 
> The simplest solution would probably be to add the `inout` keyword to the `xxx()` version, and eventually deprecate the `xxx_mut()` version

**Please don't suggest that.** The `_mut()` suffix is actually a handy mnemonic marker to gently remind the reader that the method may be mutating. Taking this away would decrease the clarity of the code.

---

<div class="post-metadata">

**Author:** ![skysch](https://avatars.discourse-cdn.com/v4/letter/s/f05b48/32.png) [@skysch](https://internals.rust-lang.org/u/skysch)\
**Post date:** [January 10, 2022, 6:15pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/3 "2022-01-10T18:15:07Z")

</div>

I have a parser combinator library, and as part of the design of that library, I had to decide whether to use `Fn` or `FnMut` for the closure types. It's a trade-off between convenient to use variable capturing and inability to parse in multiple threads, or allow parsing in multiple threads, but variable capture needs everything wrapped in `Arc` and friends.

It would be nice if I didn't have to make this tradeoff, and a proposal like this _on the surface_ appears to be trying to solve a problem like that, but then the only motivation presented is to make it trivial to write getters/setters? There are much better ways to trivialize getters (e.g., 'properties') if that were a desirable goal (which I would argue is not.)

But I can't even make sense of the following:

> `inout` types are only allowed in methods, and their mutability must be the same as the `self` argument.

If you can only mutate with `&mut self`, and you can only share with `&self`, what can you do with `&inout`? It doesn't seem to do anything except be a syntactical inference about a question with only one (obvious) answer in the first place?

And I have to second the point that just removing `_mut` is not an improvement. In addition to the fact that it is inherently helpful, you'd be asking all Rust programmers to adapt to the fact that they'd have to reinterpret all previously existing code to account for the presence of a new API design possibility. Which while not being a breaking change, is still a burden to place on people.

(Addendum: I hope people will take the time to understand this last point, because language stability is not just about semver compatibility. It's also about not burdening developers to have to make new decisions when looking at old code, and it's one of the reasons that new syntax options need strong motivations; having new ways to do old things forces everyone to ask whether the old way or new way is correct for code that is largely 'finished'. It creates churn and debate about things that previously didn't require it, which makes people feel as though they should be waiting for the language to mature even when it is already serviceable.)

---

<div class="post-metadata">

**Author:** ![derekdreery](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/derekdreery/32/2632_2.png) [@derekdreery](https://internals.rust-lang.org/u/derekdreery)\
**Post date:** [January 10, 2022, 11:42pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/4 "2022-01-10T23:42:12Z")

</div>

> [@skysch](#):
>
> If you can only mutate with `&mut self` , and you can only share with `&self` , what can you do with `&inout` ? It doesn't seem to do anything except be a syntactical inference about a question with only one (obvious) answer in the first place?

I think the point is that if you have e.g.

```rust
fn get(&self) -> &Thing;
fn get_mut(&mut self) -> &mut Thing;

```

they actually get lowered to the same machine code. They have different language semantics, but this doesn't affect execution, it just affects which programs are accepted and rejected (e.g. reject programs with shared mutable references). The function (this one probably gets inlined, but in general) could end up duplicated in machine code, and as the OP says, it leads to a larger vtable, requiring more memory with all the knock-on disadvantages associated.

You could address these issues by looking for duplicate functions, and unifying them (maybe this already happens, in rustc or LLVM), or you can have some way of linking the mutability of arguments to mutability of return types, the same way you do with lifetimes.

I don't know if `&inout Thing` is the best syntax, but I do think that having the ability to connect the shared/unique nature of refs as well as the lifetime would feel natural to rust programmers and wouldn't be a major extra cognitive burden.

---

<div class="post-metadata">

**Author:** ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)\
**Post date:** [January 11, 2022, 12:52am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/5 "2022-01-11T00:52:40Z")

</div>

> [@derekdreery](#):
>
> You could address these issues by looking for duplicate functions, and unifying them (maybe this already happens, in rustc or LLVM)

I don't think so (at least by default) because this impairs backtrace quality. The key question: which symbol name should be used if there's only one copy around?

> [@derekdreery](#):
>
> I don't know if `&inout Thing` is the best syntax, but I do think that having the ability to connect the shared/unique nature of refs as well as the lifetime would feel natural to rust programmers and wouldn't be a major extra cognitive burden.

But it'd effectively be limited to what `&mut` can do (it is not `Copy`) while at the same time being limited by what `&` can do (not mutate) within the body of the function. If this is just for these getters, what is really being gained by this? How often do these method pairs show up that they need a new keyword and API design guidelines? That kind of effect sounds like a high bar to me.

---

<div class="post-metadata">

**Author:** ![derekdreery](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/derekdreery/32/2632_2.png) [@derekdreery](https://internals.rust-lang.org/u/derekdreery)\
**Post date:** [January 11, 2022, 1:03am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/6 "2022-01-11T01:03:12Z")

</div>

> [@mathstuf](#):
>
> How often do these method pairs show up that they need a new keyword and API design guidelines?

Not saying they justify new syntax, but they do show up allll the time.

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [January 11, 2022, 1:09am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/7 "2022-01-11T01:09:15Z")

</div>

> [@mathstuf](#):
>
> How often do these method pairs show up

Basically, it shows up whenever you're "projecting" a reference through an indirection type. Most, but not all, of the cases are covered by either `Deref`/`DerefMut` (indirection to a single value) or `Index`/`IndexMut` (indirection to a collection of values).

Where being generic over reference type could see actual meaningful reduction in code duplication is for things like `MyFancyMap::get`/`MyFancyMap::get_mut`. Unless you're writing collections, though, the amount of times you'll see pairs like this is minimal.

I end up writing an absurd amount of collections for Rust code, and I personally don't really feel the need for this.

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [January 11, 2022, 1:18am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/8 "2022-01-11T01:18:53Z")

</div>

> [@mathstuf](#):
>
> > [@derekdreery](#):
> >
> > You could address these issues by looking for duplicate functions, and unifying them (maybe this already happens, in rustc or LLVM)
> 
> I don't think so (at least by default) because this impairs backtrace quality.

Well they're already deduped by LLVM in rustc today: [https://rust.godbolt.org/z/fa8e8Kb8K](https://rust.godbolt.org/z/fa8e8Kb8K)

---

<div class="post-metadata">

**Author:** ![afetisov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/afetisov/32/8508_2.png) [@afetisov](https://internals.rust-lang.org/u/afetisov)\
**Post date:** [January 11, 2022, 1:35am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/9 "2022-01-11T01:35:07Z")

</div>

> [@mathstuf](#):
>
> The key question: which symbol name should be used if there's only one copy around?

Same as with generics: in debug builds the two possible mutabilities would be monomorphized into two different functions, with mangled names which include the concrete mutability. In release builds the different copies can be merged into a single symbol, which isn't something out of ordinary. It happens with inlining, and would happen with tail call optimization.

I have definitely wanted something like that feature, but imho the presentation in the article is too limited. For example, I would like full genericity over mutability, so that generic mutability could be chained through several method calls, and could be explicitly specified in the generic parameter list (which would deprecate the `_mut` suffixes, since if you explicitly need the mutable version of the method you can just pass an explicit `mut` generic parameter). Full genericity would also allow to have different generic mutability on different parameters, which is also occasionally useful. E.g. I could write a function

```rust
fn foo<T, ''m1: mut, ''m2: mut>(x: &''m1 T, y: &''m2 T, container: Container<T>) -> &min(''m1, ''m2) T { .. }

```

which would return a `&mut T` if both arguments are `&mut T`, and `&T` otherwise.

We could also write mut-generic structures, e.g.

```rust
struct Foo<'a, ''m: mut>(&'a ''m T);

```

For example, mutable and immutable iterators can often use essentially the same data structures and code, but currently must be implemented separately. This leads either to code duplication, or to complicated macros. With mut-generics we could have something like

```rust
struct Iter<'a, ''m: mut> {
    iterable: &'a ''m Iterable,
    pos: PosInIterable,
}

impl<'a, ''m: mut> Iterator for Iter<'a, ''m> {
    type Item = &'a m Foo;
    fn next(&mut self) -> Option<Self::Item> {
        if self.iterable.size > self.pos { self.pos.increment(); }
        self.iterable.get::<''m>(self.pos)
    }
}

impl<''m: mut> Index<''m, PosInIterable> for Iterable {
    type Output = Foo;
    fn index<''m>(&''m self, idx: PosInIterable) -> &''m Foo {
        self.get::<''m>(idx).expect("no such index") 
}

```

Similarly, Fn-traits should be mut-generic, so that one could write functions which accept any closure, regardless of its capture mode.

Other types which should really be mut-generic are reference-like types, e.g. `Ref` and `RefMut` guards on the `RefCell`. If my method passes through a reference-like type (e.g. `Ref::map` or something that uses it), then I often don't really care whether you give me a mutable reference, I'll just pass through whatever Ref(Mut) type you give me.

It is quite common that I write a function which doesn't really need either mutability of its reference type, or the ability to copy references. For example, builder-pattern functions may use interior mutability, so that they can accept and return either `&Self` or `&mut Self`. I may go with the `fn foo(&self, x: Bar) -> &Self` as the more general option (it can be used on both `&Self` and `&mut Self` variables), but then the user won't be able to chain that function with some other method `fn baz(&mut self, x: Baz) -> &mut Self` which requires a mutable reference. I can define `foo` as `fn foo(&mut self, x: Bar) -> &mut Self`, which allows nice chaining, but if the consumer wants to call that method on a reference-counted builder, then they are in trouble.

---

<div class="post-metadata">

**Author:** ![robinm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/robinm/32/6255_2.png) [@robinm](https://internals.rust-lang.org/u/robinm)\
**Post date:** [January 11, 2022, 1:48am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/10 "2022-01-11T01:48:49Z")

</div>

I'm really not sure about the usefulness of `&inout`, but it would give more guaranties. `fn foo(&self) -> &inout T` guaranties that `foo()` cannot modify the object, even if the returned reference is `&mut`. I also realized that when returning `&inout` then `self` must be an immutable ref, otherwise there is no reason to not return an `&mut` inconditionnaly.

And would it be possible/useful to have `fn foo(inout self) -> inout T` means that self can be taken by (mutable/immutable) reference or by value depending on the inferred returned type?

---

<div class="post-metadata">

**Author:** ![H2CO3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/h2co3/32/2849_2.png) [@H2CO3](https://internals.rust-lang.org/u/H2CO3)\
**Post date:** [January 11, 2022, 9:24am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/11 "2022-01-11T09:24:42Z")

</div>

> [@robinm](#):
>
> And would it be possible/useful to have `fn foo(inout self) -> inout T` means that self can be taken by (mutable/immutable) reference or by value depending on the inferred returned type?

Without commenting on the usefulness of the interface, I'm wondering how you would _implement_ such a function usefully. The `self` argument isn't guaranteed to be an owned value, so any potential convenience or efficiency arising out of having ownership goes right into the waste – the compiler can't allow moving out of it, for example. At that point, it looks like it would be an easy-to-misuse interface that can introduce, for example, silent clones and related performance bugs (always cloning can mysteriously transform an `O(N)` algorithm into an `O(N^2)` one).

---

<div class="post-metadata">

**Author:** ![robinm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/robinm/32/6255_2.png) [@robinm](https://internals.rust-lang.org/u/robinm)\
**Post date:** [January 11, 2022, 1:55pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/12 "2022-01-11T13:55:41Z")

</div>

Without commenting either on the usefulness of the interface, the reason to have `inout self` possibly deducing to a value would be similar to the rational behind the `deducing this` proposal for C++23, especially the [section on move or copy into parameters](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0847r5.html#move-into-parameter).

> Say you wanted to provide a `.sorted()` method on a data structure. Such a method naturally wants to operate on a copy. Taking the parameter by value will cleanly and correctly move into the parameter if the original object is an rvalue without requiring templates.
> 
> ```c++
> struct my_vector : vector<int> {
> auto sorted(this my_vector self) -> my_vector {
> sort(self.begin(), self.end());
> return self;
> }
> };
> 
> ```

> **Is this useful?**
>
> The reason I’m not sure the rationals for C++ deducing this proposal apply to Rust are:
> 
> - C++ is copy by default (with explicit move), where Rust has explicit call to `.clone()` and implicit move. Because of this, creating a copy before sorting is harder to in C++ (`auto copy = my_vec; copy.sorted();`), while it’s a simple `my_vec.clone().sort()` in Rust.
> - Move in C++ is non-destructive, which means that the caller will unconditionally call the destructor of a moved-from object (and thus a moved-from object must have an empty state if needed to be destructible), while Rust move are destructive (so the destructor of a moved-from object is never called, and thus can be left in an invalid state).
> 
> But it _may_ be possible that you _may_ want to implement a function similar to `sorted()` function on a wrapper type, which always return by value either by consuming the wrapper (`Fn(Wrapper) -> Value`) or by cloning what is needed inside the wrapper (`Fn(&Wrapper) -> Value`). This construction is only useful if `sorted()` when taking an immutable ref doesn’t need to clone the whole `Wrapper` object.

---

<div class="post-metadata">

**Author:** ![derekdreery](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/derekdreery/32/2632_2.png) [@derekdreery](https://internals.rust-lang.org/u/derekdreery)\
**Post date:** [January 15, 2022, 10:57pm UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/13 "2022-01-15T22:57:31Z")

</div>

I also saw there was a working group for "polymorphization", which I think is targeted at problems like this?

---

<div class="post-metadata">

**Author:** ![PoignardAzur](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/poignardazur/32/6464_2.png) [@PoignardAzur](https://internals.rust-lang.org/u/PoignardAzur)\
**Post date:** [January 16, 2022, 11:26am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/14 "2022-01-16T11:26:07Z")

</div>

> [@H2CO3](#):
>
> But then what do you justify this kind of feature with? Apart from trivial getter/setters (which are non-idiomatic and rare in the first place) and the 3 standard ref-to-ref conversions ( `AsRef` , `Borrow` and `Deref` ), there doesn't seem to be much space for methods that may be either mutable or immutable _and_ share the same implementation.

Well, right now I'm working on a library with lots of access patterns and tree visiting (kind of like what @CAD97 mentions), and I have to write a lot of methods like `find_child / find_child_mut` that have virtually the same code except the mut version uses `iter_mut` instead of `iter`, so the code duplication is non-trivial.

> [@](#):
>
> Mutable references are different enough qualitatively, in their nature, that allowing mutation vs. allowing sharing doesn't usually warrant copy-pasting any non-trivial implementations. And adding a separate language feature for them seems like an overkill.

I disagree. There's a lot of collection code where the `_mut` version of a method does the exact same thing, down to the machine code executed. Eg the tree visiting mentioned above.

> [@skysch](#):
>
> I have a parser combinator library, and as part of the design of that library, I had to decide whether to use `Fn` or `FnMut` for the closure types. It's a trade-off between convenient to use variable capturing and inability to parse in multiple threads, or allow parsing in multiple threads, but variable capture needs everything wrapped in `Arc` and friends.
> 
> It would be nice if I didn't have to make this tradeoff, and a proposal like this _on the surface_ appears to be trying to solve a problem like that, but then the only motivation presented is to make it trivial to write getters/setters?

Can you give an example of some of the code that could be improved by having parametric mutability?

> [@](#):
>
> And I have to second the point that just removing `_mut` is not an improvement. In addition to the fact that it is inherently helpful, you'd be asking all Rust programmers to adapt to the fact that they'd have to reinterpret all previously existing code to account for the presence of a new API design possibility.

Yeah, I did underestimate the "breaking habits" part of this proposal. A more modest proposal would be to leave existing methods as-is but use `inout` for new methods, but that comes with its own problems.

> [@derekdreery](#):
>
> I also saw there was a working group for "polymorphization", which I think is targeted at problems like this?

Not really the same thing, no. Polymorphization is about generating less code _before_ passing it to LLVM.

* * *

I think I did a poor job of explaining why I'd want this feature. The goal wouldn't just be deduplication of code. The goal would be to express "this function works the same way internally whether it gets shared references or mutable references, but returns the same type you put in".

In that sense, it would be like lifetimes: a way to express the "logic" is generic over an effect, but the actual code is the same independently of parameters passed.

Except I was kind of trying to express this in a concise way, which probably doesn't work; it's like trying to implement lifetime elision before lifetimes.

---

<div class="post-metadata">

**Author:** ![Aloso](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aloso/32/5039_2.png) [@Aloso](https://internals.rust-lang.org/u/Aloso)\
**Post date:** [January 18, 2022, 4:04am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/15 "2022-01-18T04:04:18Z")

</div>

I think this would be quite useful if structs can contain `inout` references:

```rust
struct MyIter<'a, I> {
    inner: &'a inout MyCollection<I>,
}

impl<'a, I> Iterator for MyIter<'a, I> {
    type Item = &'a inout I;

    ...
}

```

So you only need to implement 2 iterators (borrowed and owned) instead of 3.

---

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [January 19, 2022, 1:14am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/16 "2022-01-19T01:14:22Z")

</div>

The difficulty is that borrowed references are either shared or exclusive. A reference can't be shared and exclusive at the same time — it's a logical impossibility. So the compiler would have to figure out when exactly it was meant to have shared semantics, and when it has exclusive semantics.

---

<div class="post-metadata">

**Author:** ![Aloso](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aloso/32/5039_2.png) [@Aloso](https://internals.rust-lang.org/u/Aloso)\
**Post date:** [January 19, 2022, 1:46am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/17 "2022-01-19T01:46:04Z")

</div>

> [@kornel](#):
>
> A reference can't be shared and exclusive at the same time

The key insight is that uniqueness is a strong guarantee whereas "sharedness" is more of a limitation as it prevents unsynchronized mutation. Exclusive references are _strictly more powerful_ than shared references, which is evident since `&mut T` can be coerced to `&T`, but not the other way around.

Therefore it shouldn't be a problem to treat `inout` references like shared references. There is just one additional limitation: The borrow checker has to ensure that `inout` references don't alias, so the uniqueness is preserved. They can still be immutably borrowed though.

This essentially makes `inout` references the "least common denominator" of shared and exclusive references.

---

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [January 19, 2022, 3:50am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/18 "2022-01-19T03:50:24Z")

</div>

What can it do that a `&mut` reference can't?

---

<div class="post-metadata">

**Author:** ![Aloso](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aloso/32/5039_2.png) [@Aloso](https://internals.rust-lang.org/u/Aloso)\
**Post date:** [January 19, 2022, 8:20am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/19 "2022-01-19T08:20:48Z")

</div>

Looking at this code sample from the post:

```rust
fn get_value(&self) -> &inout Value {
  self.value
}

```

Though I _think_ it should be `(&inout self) -> &inout Value`.

It returns `&mut Value` only when `self` is mutably borrowed, otherwise it returns `&Value`. It's like `get_value` and `get_value_mut` in one.

---

<div class="post-metadata">

**Author:** ![PoignardAzur](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/poignardazur/32/6464_2.png) [@PoignardAzur](https://internals.rust-lang.org/u/PoignardAzur)\
**Post date:** [January 19, 2022, 9:49am UTC](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944/20 "2022-01-19T09:49:12Z")

</div>

> [@kornel](#):
>
> The difficulty is that borrowed references are either shared or exclusive. A reference can't be shared and exclusive at the same time — it's a logical impossibility.

Conceptually, the reference isn't shared and exclusive at the same time.

Rather, the "sharedness" of the reference is more like a generic parameter. The same function is instantiated for mutable and immutable refs. And like with lifetime parameters, the rules a made in such a way that shared and exclusive references use the same monomorphization.

[Next page](https://internals.rust-lang.org/t/rust-2030-christmas-list-inout-methods/15944.md?page=2)