Getting Started with Tokio • Hacker News Board

Re: Getting Started with Tokio

#11

Post by Arnavion » Sat, Dec 24, 2016, 8:54 PM UTC

steveklabnik wrote: post #10

Arnavion wrote: post #7

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

In 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...)

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

Re: Getting Started with Tokio

#12

Post by kibwen » Sat, Dec 24, 2016, 9:53 PM UTC

Very happy to see this, Tokio is still so primordial that it's sadly underdocumented. Looking forward to seeing that change in the coming year. :)

Re: Getting Started with Tokio

#13

Post by lukes386 » Sat, Dec 24, 2016, 10:31 PM UTC

Arnavion wrote: post #11

steveklabnik wrote: post #10

Earlier quoted context omitted.

In 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...)

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.

Re: Getting Started with Tokio

#14

Post by Manishearth » Sun, Dec 25, 2016, 1:46 AM UTC

steveklabnik wrote: post #10

Arnavion wrote: post #7

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

In 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...)

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"

Re: Getting Started with Tokio

#15

Post by rabidferret » Sun, Dec 25, 2016, 2:14 AM UTC

Manishearth wrote: post #14

steveklabnik wrote: post #10

Earlier quoted context omitted.

In 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...)

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;…

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.

Re: Getting Started with Tokio

#16

Post by thinkpad20 » Sun, Dec 25, 2016, 3:02 AM UTC

steveklabnik wrote: post #10

Arnavion wrote: post #7

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

In 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...)

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

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

Re: Getting Started with Tokio

#17

Post by Rusky » Sun, Dec 25, 2016, 5:05 AM UTC

thinkpad20 wrote: post #16

steveklabnik wrote: post #10

Earlier quoted context omitted.

In 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...)

> 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`.

Re: Getting Started with Tokio

#18

Post by Manishearth » Sun, Dec 25, 2016, 6:03 AM UTC

rabidferret wrote: post #15

Manishearth wrote: post #14

Earlier quoted context omitted.

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;…

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.

Re: Getting Started with Tokio

#19

Post by steveklabnik » Sun, Dec 25, 2016, 5:33 PM UTC

thinkpad20 wrote: post #16

steveklabnik wrote: post #10

Earlier quoted context omitted.

In 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...)

> use the nightly-only "-> impl Trait" Can someone point me to more info on this? Possibly akin to existential types in Haskell?

https://github.com/rust-lang/rfcs/blob/master/text/1522-cons...

Re: Getting Started with Tokio

#20

Post by rabidferret » Sun, Dec 25, 2016, 6:50 PM UTC

Manishearth wrote: post #18

rabidferret wrote: post #15

Earlier quoted context omitted.

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.