this is so each step of the accept process is cancel-safe
we might want to deprecate the combined fn.
Questions:
leave the combined one in? NO
should accept return a Result<impl Future...> or a Result<Accepting> where Accepting has a fn that resolves to a future?
returning a concrete type that implements Future itself is not possible without boxing, and I don't want to do this because we care about allocations for the mem path.
impl Future: works fine if you use it as is, but might be a pain if you want to pass it to a handler fn
concrete type: is slightly less verbose in direct use, but easier when passing to a handler fn
this is so each step of the accept process is cancel-safe
we might want to deprecate the combined fn.
Questions:
leave the combined one in? NO
should accept return a
Result<impl Future...>or aResult<Accepting>where Accepting has a fn that resolves to a future?returning a concrete type that implements Future itself is not possible without boxing, and I don't want to do this because we care about allocations for the mem path.
impl Future: works fine if you use it as is, but might be a pain if you want to pass it to a handler fn
concrete type: is slightly less verbose in direct use, but easier when passing to a handler fn