Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chan::async() conflicts with Rust 2018 Edition #31

Closed
troiganto opened this issue Jul 28, 2018 · 6 comments
Closed

chan::async() conflicts with Rust 2018 Edition #31

troiganto opened this issue Jul 28, 2018 · 6 comments

Comments

@troiganto
Copy link

In Rust 2018, async will become a keyword and conflict with the async() function that chan currently defines. I only noticed this because cargo fix is currently unable to handle this case. The workaround right now is to add this line to the top of the crate:

#![feature(raw_identifiers)]

and replace chan::async() with chan::r#async(). However, in the long term, it might be a good idea to pick a different name. The chan::sync() function would likely have to be renamed as well, in order to stay symmetric.

Despite this small issue, thank you for your work on this crate! I've used it several times now and it has always been a pleasure to work with. 🙂

@BurntSushi
Copy link
Owner

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

@BurntSushi
Copy link
Owner

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

@troiganto
Copy link
Author

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!

@BurntSushi
Copy link
Owner

@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

@BurntSushi
Copy link
Owner

BurntSushi commented Jul 31, 2018

@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)
}

@djahandarie
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants