Update to tokio 1.0

[fenhl]

With its optional tokio 0.3 dependency, iced is in an awkward position where if you want to use those features, iced is incompatible with many other crates that skipped tokio 0.3 and moved directly from tokio 0.2 to tokio 1. tokio 1's API is almost identical to that of tokio 0.3, so a small release updating to it would be appreciated.

[hecrj]

Is there any particular reason why relying on master is inadequate for you?

I have plans to start releasing more frequently.

[fenhl]

Git dependencies are a lot harder to work with because they don't have easily accessible docs. I wasn't even aware that the dependency was already updated here.

[valbendan]

I think a new minor release with tokio 1.0 support is necessary, but I can wait If you will release a new version in next few weeks(2 ~ 4 weeks).

I can backport tokio 1.0 to 0.2 version.

[ahirner]

On master, trying to cargo run --package download_progress --features tokio produces this error on mac os:

   Compiling winit v0.24.0
error[E0308]: mismatched types
   --> futures/src/time.rs:100:17
    |
100 | /                 futures::stream::unfold(
101 | |                     tokio::time::interval_at(start, self.0),
102 | |                     |mut interval| async move {
103 | |                         Some((interval.tick().await, interval))
104 | |                     },
105 | |                 )
    | |                 ^- help: try adding a semicolon: `;`
    | |_________________|
    |                   expected `()`, found struct `futures::stream::Unfold`
    |
    = note: expected unit type `()`
                  found struct `futures:

Adding that semicolon (naturally) produces a warning:

warning: unused `futures::stream::Unfold` that must be used
   --> futures/src/time.rs:100:17
    |
100 | /                 futures::stream::unfold(
101 | |                     tokio::time::interval_at(start, self.0),
102 | |                     |mut interval| async move {
103 | |                         Some((interval.tick().await, interval))
104 | |                     },
105 | |                 );
    | |__________________^
    |
    = note: `#[warn(unused_must_use)]` on by default
    = note: streams do nothing unless polled

The example, however runs without noticeable differences. cargo tree --package download_progress --features tokio | grep "tokio v0.2" | wc tells me about 7 0.2 dependencies. Will examples also be taken care of in this issue or should I add a new one?

PS: I took this example as starting point to see how running background services with an iced frontend plays out.

[hecrj]

@ahirner The Cargo.toml of each example enables the appropriate features. You don't need to enable independent features when running them.

For instance, download_progress relies on tokio_old.

[dancespiele]

In my case I need the next release of iced in order to release the first version of https://github.com/dancespiele/okspiel otherwise If I use the version of 0.2 I will have conflict with tokio version because rqwest use tokio 1.0 in the last version and the previous version use 0.2 but Iced 0.2 use tokio 0.3. Neither cargo doesn't allow me publish any app that contain dependencies without versions or target to git repository

error: all dependencies must have a version specified when publishing.
dependency `iced` does not specify a version
Note: The published dependency will use the version from crates.io,
the `git` specification will be removed from the dependency declaration.