Owned references to contents in an earlier stack frame (`&own`, `&move`, etc)

[nikomatsakis]

A common request is to have a way to pass a reference that actually owns its referent. The idea originated long ago in an attempt to find a suitable type for Drop, but it's not a perfect fit there (you really want to not own the struct being dropped, just its fields). It has since resurfaced as a means to pass ownership of unsized types (but see #990 as well) and various other use cases.

Postponed RFCs

• #965
• #1617

[ticki]

👍 Doing this in a safe way w/o heap allocation would be neat.

[ticki]

Are there any unresolved questions?

[burdges]

It sounds like a comonad actually, so state machines, etc.

There is an RFC proposing impl delegation here : #1406

I'd imagine this could be done by delegating several impls to a reference pointer, while offering a destroy routine that returns the referent pointer, otherwise kept hidden and unsafe. In many situations, destroy would return an index too. I donno if this pattern could be abstracted to encapsulate the unsafe somehow.

There isn't afaik any reason to touch the usual comonad definition here, but comonads do run close to object oriented programming http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html It's not too odd that an RFC for adding a form of inheritance would help add the most well understood application of comonads too.

[cramertj]

Alternatively, is there a clean way to make references more extensible in general? It seems to me that an alternative approach that allowed substitution of references for anything implementing Deref would be really useful. For example, in public library structs with internal references, it seems like references are too limiting: really, the user should be able to provide a reference, Rc, Arc, Box, or whatever they please. The obvious answer is to make every such struct generic on Deref, but that adds a lot of unnecessary boilerplate (SomeStruct<Deref<Target = RefType1>, Deref<Target = RefType2>, ...>) in comparison with simple references.

[pnkfelix]

@cramertj I think what you are asking for are higher-kinded types (HKT)?

so that one could have a library parameterized over a type constructor from type to type (and I guess also in this case the type resulting from the construction would be expected to implement Deref in an appropriate manner); then you would instantiate such a library with the desired reference type constructor: Rc, Arc, Cow, .,..

If that is indeed what you are describing, then yes, HKT is something the community has been discussing for a long while. (However, I believe it to be separate from the construct described on this ticket, at least in the sense that whether or not we add HKT is largely orthogonal to whether we add a &own that the borrow checker knows how to reason about )

[cramertj]

Yes, I'm essentially proposing a specific use case of HKTs. I wasn't sure whether or not this RFC was designed with HKTs in mind-- perhaps I don't properly understand the concept of own. Given the application of HKTs I suggested, why must &own be a special type of reference separate from a generic Own<T> in the standard library? It seems like Own could just be a simple wrapper struct with a single field of type T, which could be factored out at compile time.