# Having mutability in several views of a struct
**URL:** https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882
**Category:** language design
**Created:** [March 2, 2018, 2:41pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882 "2018-03-02T14:41:35Z")
**Posts on this page:** 7
**Page:** 2
### Author:  [@Soni](https://internals.rust-lang.org/u/Soni)
#### Post date: [November 7, 2018, 12:48pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/21 "2018-11-07T12:48:35Z")
> [@H2CO3](#):
>
> (Oh my gosh that syntax looks really ugly btw, just wanted to come up with something quickly.)
```rust
fn foo(&self(bar, baz), other: &Self(bar, baz))
```
(from PIT thread)
---
### Author:  [@dan\_t](https://internals.rust-lang.org/u/dan_t)
#### Post date: [November 7, 2018, 1:46pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/22 "2018-11-07T13:46:24Z")
One could also mimic the field access syntax:
fn foo(&self.bar, other: &Self.bar)
And for multiple fields the ‘use’ syntax:
fn foo(&self.{bar, baz}, other: &Self.{bar, baz})
---
### Author:  [@Ixrec](https://internals.rust-lang.org/u/Ixrec)
#### Post date: [November 7, 2018, 1:50pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/23 "2018-11-07T13:50:47Z")
One thing I’m not super clear on when it comes to this whole inter-procedural borrow checker interference with disjoint `self` borrows issue:
Does this typically happen when the fields being borrowed are already public? Or are they typically private?
Because if they’re private, then `fn foo(&self.{bar, baz})` is solving the problem by putting private fields into your public API signatures. But if they’re already public, then it seems worth the hassle of breaking up the struct into multiple public types to make an explicit commitment to their disjointness.
---
### Author:  [@H2CO3](https://internals.rust-lang.org/u/H2CO3)
#### Post date: [November 7, 2018, 1:50pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/24 "2018-11-07T13:50:53Z")
…which in turn makes me think: why don’t we just pass those fields as separate references in a similar situation? Then it wouldn’t require global reasoning (nor any modification of the language).
---
### Author:  [@Soni](https://internals.rust-lang.org/u/Soni)
#### Post date: [November 7, 2018, 2:23pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/25 "2018-11-07T14:23:17Z")
the PIT thread also proposed something interesting: tuple structs leak implementation details, as such maybe we should too.
---
### Author:  [@BatmanAoD](https://internals.rust-lang.org/u/BatmanAoD)
#### Post date: [November 7, 2018, 5:12pm UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/26 "2018-11-07T17:12:21Z")
> [@RustyYato](#):
>
> Does `view` specify which fields are being referenced and what mutability they have, if not then it is still action at a distance.
No; I was trying to come up with a syntax that would fulfill @nikomatsakis's "idea that it would be nice... for the compiler to do the inference for you."
I also don't quite agree that this is "action at a distance", since the set of fields included in the view is determined where the `view` keyword is used. But you're right that when used in a public API, the permissible calling contexts would depend on the function implementation, so I see why you'd use that phrase.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [March 25, 2019, 8:29am UTC](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882/27 "2019-03-25T08:29:44Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
[Previous page](https://internals.rust-lang.org/t/having-mutability-in-several-views-of-a-struct/6882.md?page=1)