Allow immutable access of &mut struct field through &self

[bluss]

I can access a &mut int through a & &mut int pointer:

 let x = &mut ~3; let y = &x; ***y   // evaluates to `3`

But not access a &mut struct field through &self:

struct Ref<'self, T>(&'self mut T);
let mut it = range(0,3);
let r = &Ref(&mut it);
r.size_hint()
// error: cannot borrow an `&mut` in a `&` pointer; try an `&mut` instead

The use case is precisely Ref above, in essence, I want to implement a "by-ref" (by mutable ref) adaptor for iterators. And it works fine for implementing Iterator::next but not for Iterator::size_hint for the reason above.

[bluss]

There is a high chance I'm just plain wrong and it's impossible for a good reason.

[bluss]

Relevant testcase for denying this: ./src/test/compile-fail/borrowck-borrow-mut-base-ptr-in-aliasable-loc.rs

[nikomatsakis]

I think we could permit immutable or const borrows of &mut data found in an & position, so long as we prohibit writes (which we currently do). My notes in the borrowck docs also suggest as much. The argument being: that the aliasable &mut pointer is the only way to write, and it cannot be used to write, so the data is effectively immutable.

It is not the case that &const &mut T could be frozen though, because the &const borrow can co-exist with some other &mut &mut T borrow.

[nikomatsakis]

See #9953 for an additional test case.

[nikomatsakis]

I have been thinking about this lately and have come to the conclusion that it is best to consider an &mut that is found from an & (but not &const) pointer to be frozen. There is no way that it could be legally mutated (for the lifetime of the outer pointer) -- and it seems useful for composition (i.e., if you have something like

struct BorrowedMap<'a> {
    x: &'a mut HashMap
}

and then you have an &self function, you can still use the enclosed hashmap, just as if it was owned).

[nikomatsakis]

Assigning myself.

[nikomatsakis]

Note there is a subtle condition to get right, analogous to #8624: If we have x: &'a &'b mut T, we can freeze **x but only up to the lifetime 'a (which must in turn be a sublifetime of 'b).

[pnkfelix]

cc me

[ziad-exabeam]

Should this be closed given that it was fixed by PR #10787?

[luqmana]

@ziad-exabeam yep, thanks!