I'm not really sure if that advice is accurate. For both iterators and futures, in most cases you will be returning a concrete type which can be named. You only really need to box it if you have a closure involved (and if you have a complicated adapter chain it becomes cleaner to box/impl trait it)

E.g. in this case there's no specific compulsion to use a trait object.

I wouldn't consider this to be a rule of thumb; it's more like "if you have trouble naming the return type try using Box<Trait>"

Just because a type can be named doesn't mean that returning the named type properly expresses your intent.

The name of said type can get real hairy real fast, as well.

Right, but in most cases returning a named type is fine. Usually with futures/iterators I've seen that you end up returning a new custom type that implements the trait, and often it's okay to just name it.

I think that's only the case when you are specifically trying to avoid boxing.

> use the nightly-only "-> impl Trait"

Can someone point me to more info on this? Possibly akin to existential types in Haskell?

It's not really existential types in the general sense. A function returning `impl SomeTrait` can still only return values of a single type, it's just that the compiler infers that type from the function body and then restricts the caller to accessing that value via the methods in `SomeTrait`.

Yeah that's what I was thinking; e.g. in Haskell you can use existential types to refer to "some type which implements this type class", and then an object of that type will have the functions in that type class available to it and no others (more or less). Cool that rust has this as well, I'm excited to learn about it.

Rust has something else more general that's much closer to existentials- you can use trait objects to erase a value's type and restrict methods on it to those in the trait.

The difference between trait objects and `impl Trait` is that trait objects can hold any value that implements a trait, since they're implemented via dynamic dispatch.

In general, yes. But here I don't see why it's not possible to use FutureResult instead of BoxFuture.

Yep, you're right, a plain FutureResult works fine in this case. I was aware of the general rule about boxing futures, but didn't realize it was unnecessary in this case. Thanks for pointing it out! I'll update the post.