5 ms·
>You can ignore all of the Box stuff; the reasoning behind that isn't terribly important right now. What is the reason to box the futures? futures::finished an
by Arnavion 10y ago
>You can ignore all of the Box stuff; the reasoning behind that isn't terribly important right now.
What is the reason to box the futures? futures::finished and futures::failed both return FutureResult.
- steveklabnik 10y agoIn general, Future is a trait, which means if you want to return a Future, you have to either create a trait object, or use the nightly-only "-> impl Trait". Boxing is the most straightforward way of creating a trait object. (I haven't dug into the specifics of this specific example; that's what I assumed when I read that line. Maybe the author also knew this rule of thumb and did it unnecessarily...)
- Arnavion 10y agoIn general, yes. But here I don't see why it's not possible to use FutureResult instead of BoxFuture.
- lukes386 10y agoYep, 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.
- Manishearth 10y agoI'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>"
- rabidferret 10y agoJust 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.
- Manishearth 10y agoRight, 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.
- rabidferret 10y agoI think that's only the case when you are specifically trying to avoid boxing.
- thinkpad20 10y ago> use the nightly-only "-> impl Trait" Can someone point me to more info on this? Possibly akin to existential types in Haskell?
- Rusky 10y agoIt'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`.
- thinkpad20 10y agoYeah 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.
- Rusky 10y agoRust 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.
- steveklabnik 10y agohttps://github.com/rust-lang/rfcs/blob/master/text/1522-conservative-impl-trait.md https://github.com/rust-lang/rfcs/blob/master/text/1522-cons...