undefined | Better HN

0 pointsManishearth9y ago0 comments

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>"

0 comments

rabidferret9y ago

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.

ManishearthOP9y ago

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.

rabidferret9y ago

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

j / k navigate · click thread line to collapse

0 pointsManishearth9y ago0 comments

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>"

0 comments

rabidferret9y ago

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.

ManishearthOP9y ago

rabidferret9y ago

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

j / k navigate · click thread line to collapse