solve the borrow issue with the LRU cache? about collect-rs

[Gankra]

This SO post predates the Entry API, which is exactly the solution to their problem, as far as I know.

Can you post some modern code that is causing you trouble?

[andrewrk]

I am indeed using the Entry API and running into the same problem: https://github.com/andrewrk/genesis/blob/18e9b1db57de8c3c5dd06904c482d274a7048240/src/text.rs#L123

[Gankra]

So what's wrong here? To insert an element you need mutable rights. The fact that it returns a mutable ref that you have to coerce to immutable seems minimal.

[andrewrk]

It ends up using the lifetime from &'a mut self instead of an immutable lifetime. So the cache value that gets returned is a mutable ref when I wanted an immutable ref. This causes a compile error when you try to use another field from the struct that contains the hash map.

[Gankra]

Sounds like a bug in Rust, but maybe this is fundamental.

[Gankra]

@pcwalton is this intended behaviour? &*(&mut T) prevents future immutable borrows of T?

[tbu-]

@gankro FWIW it's always been the case.

[bluss]

My argument was that in general borrows are not tagged by mutability. Look at this:

fn borrow_thing<'a>(&'a mut self) -> Response<'a> { ... }

If Response<'a> would be a &'a T instead, you would think it's illogical. We really can't tell if this is a "true" mutable borrow or not. But in general borrows keep track of what they are derived from, right, not what they produce.

[Gankra]

Ah okay I talked it out with @nikomatsakis on IRC and there's literally nothing that can be done here with Rust's current type system. Evidently the borrow system does not look at return types to decide the kind of borrow. If you use the lifetime 'a from an &'a mut, it will always behave as a mutable borrow regardless of what the 'a is stored in.

That is, fn foo<'a>(&'a mut self) -> &'a Foo will have &'a Foo behave as an &'a mut Foo for the purposes of borrow checking. I do not believe that this is a fundamental problem with Rust. The alternative would simply require spidering the return type of a function to "infer" the mutability of the borrow. Currently borrow checking doesn't need to look at the contents of the return type beyond what lifetimes it contains. And indeed it would be harder for a reader of the API to determine the mutability of the borrow in general if this was done. e.g. today if we see fn foo<'a>(&'a mut self) -> Foo<'a> we know the Foo mutably borrows self, but the proposed system would require a consumer to know the internals of Foo to know the mutability of the borrow. Since we encourage private-by-default, this may not be trivial to find out.

[Gankra]

I'm closing this as cant-fix. This is fundamental to the current language design. No API change can handle this if the method needs to take &mut self.

[andrewrk]

Thanks for looking into it.

[Gankra]

@andrewrk As a hack, you can potentially convert the &mut to a raw ptr, convert it back to an &'static, and then copy_lifetime it with &my_map to make it into a proper shared reference to the insides of the my_map. But this can't be returned from a method that takes &mut my_map, or else it will just get re-upgraded to an owned borrow.