Closures in API design – theoretical limitations and best practices?

I think, I don’t see how that helps much, as the coerce function relies on being able to provide a more concrete Fn…(…) -> … bound that expresses the true signature of the closure to help out type inference. Whereas with the case of returning a future, you can never properly write the returned Future type, so writing a good signature for coerce is just as problematic (unless it’s a nameable future type, which is the whole point of using the BoxFuture workaround; or, apparently, as you demonstrated, unless TAIT is used).