Having mutability in several views of a struct

[nikomatsakis]

This is definitely hitting at a real problem, specifically the need to have helper functions that touch disjoint sets of fields which can overlap.

This previous thread also discussed the same general topic:

Partial self borrowing syntax

Yeah, but you don’t actually want to be forced to make your fields public. In any case, at this point we are walking right into a whole field of research about how best to specify which APIs can be composed with what – i.e., you might like to be able to say things like "the method foo can be called in parallel with bar", without having to say what state they affect. One way to do this that I personally pursued as part of my PhD is to partition the state abstractly, so that you can say “the met…

The idea of explicit views is interesting; as I mention in that thread, I've been leaning towards the idea that it would be nice -- at least for private functions -- for the compiler to do the inference for you. But I've been wanting some kind of explicit syntax as well.

I actually do something sort of like explicit views occassionally in my own coding. That is, I create "shadow structs", like:

struct RealStruct {
    foo: Foo,
    bar: Bar,
    baz: Baz,
}

struct ShadowStruct<'a> {
    foo: &'a Foo, // foo is immutable
    bar: &'a mut Bar, // bar and baz are not
    baz: &'a mut Baz,
}