In the case of implementing Sink, we are given an unbounded lifetime of &mut self or mut self: Pin<&mut Self>. However, let's say you want to pass on a mutable borrowed reference (which exists as an owned type within a vector) from the poll function into another structure which stores that mutable reference in a VecDeque. If this is passed from the poll function, the borrow checker, in my experience, isn't happy because the closure of poll expires before the mutable borrow. The way to alleviate this unsafely is by doing this
then I'd pass that mutable borrow into a closure that requires a lifetime of `a (where it is therefrom stored)
However, is this truly safe if I guarantee that no two mutable borrows will be alive simultaneously? My program's logic already guarantees this; I'm just wanting to pass around mutable borrows of packets around different stages of processing
you have created two aliasing unique references, this and self (because extend_lifetime's return value does not borrow from the incoming reference the reborrow generated for it only lasts until extend_lifetime returns).
If you want to do lifetime shenanigans to work around borrow checker limitations you must use raw pointers, and in the case of implementing Sink where you are passing that pointer outside of its lifetime then you cannot ever turn that raw pointer back into a reference as you do not have control over when your owner may create a new unique reference to yourself. (Unless this is single-threaded and you are very, very careful about when you are polled versus running the closure, but then implementing a general purpose trait like Sink is not a good idea).
I am using a ThreadPool for an executor, and as such, I am not sure if my program is using a single thread or multiple for the Future which drives my packet system. Even if I did know, I would want perhaps several threads in the case that there is heavy backpressure in downstream sinks.