chan::async() conflicts with Rust 2018 Edition about chan HOT 6 CLOSED

For anyone trying to use async() on rust 2018, you can still use it via r#async(). (The compiler gives you this hint if you're trying to write chan::async() but not if it's imported at the top-level.)

Of course, this crate has been deprecated for https://github.com/crossbeam-rs/crossbeam-channel, so the long-term fix is likely moving over there.

from chan.

I don't think we need to rename anything? This crate should continue to work via Rust 2015.

from chan.

@troiganto Also, I expect to end-of-life chan in favor of https://github.com/crossbeam-rs/crossbeam-channel. The APIs are very similar, but the implementation quality is much higher and the select macro is much nicer.

from chan.

I see, sorry for the noise then. I mainly stumbled over chan because of chan-signal, which seems to be the most fleshed-out way to handle signals on Unix so far. But if we're talking about an end-of-life situation, it'll likely make sense to switch to another crate for that, as well.

In any case, thanks for the speedy and helpful response!

from chan.

@troiganto Yeah, I really need to just update the READMEs for this project. crossbeam-channel is definitely the path forward at this point. I do expect to end-of-life chan-signal as well. My hope is that someone builds a similar crate for handling signals using crossbeam-signal. See: BurntSushi/chan-signal#27

from chan.

@troiganto Doing a brief investigation, @vorner's signal-hook library looks very promising: https://crates.io/crates/signal-hook

You can basically re-create chan-signal with something like this, while swapping out whatever channel implementation you want:

fn signal_notify(signals: &[c_int]) -> Result<chan::Receiver<c_int>> {
    let (s, r) = chan::sync(100);
    let signals = signal_hook::iterator::Signals::new(signals)?;
    thread::spawn(move || {
        for signal in signals.forever() {
            s.send(signal);
        }
    });
    Ok(r)
}

from chan.