FnPin and FnPinMut: closures that return borrows of their captures

language design
1

Rough sketch: Rust Playground

trait FnPin<'a, Args>: FnPinMut<'a, Args> {
    fn call_pinned(self: Pin<&'a Self>, args: Args) -> Self::Output;
}

trait FnPinMut<'a, Args> {
    type Output;
    
    fn call_pinned_mut(self: Pin<&'a mut Self>, args: Args) -> Self::Output;
}

type IsDynCompatible = dyn FnPin<'a>() -> &'a [u8];

fn borrow_owned() -> impl FnPin<'a>() -> &'a [u8] {
    let vec = Vec::<u8>::new();
    move || &vec
}
2

This does look both a) potentially useful (although I don't immediately have a use case) and b) something that could be validly implemented, but I'm wondering whether it's more restrictive than it could be.

When I saw the API, I immediately tried to implement it in terms of coroutines (an unstable feature), but it didn't quite work – what's actually needed is a lending coroutine, so that the lifetime of the return value can be matched to the lifetime of the &mut in the Pin<&mut self> receiver of resume.

And that made me think of lending iterators – the API is basically identical to a lending iterator, except that it returns Self::Output rather than Option<Self::Output> (which doesn't seem like a significant change in terms of implementability) and requires pinning. (Most of the examples of lending iterators I found online reborrow from their closure captures rather than borrowing them directly, and thus don't require pinning – but I think I've seen versions that borrow directly and do). So I suspect that it would make sense to base this on whatever ends up happening with respect to (pin-requiring) lending iterators, as the constraints it would put on the compiler and type system are very similar. (It might be that once progress has been made on coroutines, generators, or lending iterators, that something like this would become a trivial library wrapper and doesn't require compiler support.)

(EDIT: I found some prior art on Niko Matsakis's blog – it's missing the Pin but intended for use with async, so may need one.)

3

You could still implement it with coroutines if you're willing to play around with unsafe binders. :sweat_smile:

I now realize that most cases can be handled by a lending fn without the pinning requirement.

e.g. owning a ptr to a slice and returning borrows from it.

fn project<T>(i: usize, slice: Arc<[T]>) -> impl Fn<'a>() -> Option<&'a mut T> {
  move || {
    &slice[i]
  }
}

And lending coroutines would be a generalization of FnPinMut.

So that leaves FnPin as a special case where the closure is self referential and only contains interior mutability. Which is quite niche in retrospect.