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

Stable Rust now that GATs are stable? #129

Closed
rtfeldman opened this issue Nov 10, 2022 · 3 comments · Fixed by #227
Closed

Stable Rust now that GATs are stable? #129

rtfeldman opened this issue Nov 10, 2022 · 3 comments · Fixed by #227
Labels
F-feature-request feature request

Comments

@rtfeldman
Copy link

Thanks for making this library!

I noticed in the readme that GATs are a reason for depending on nightly Rust instead of stable. Now that GATs have just landed in stable, is it possible for monoio to depend on stable?

@rtfeldman rtfeldman added the F-feature-request feature request label Nov 10, 2022
@ihciah
Copy link
Member

ihciah commented Nov 16, 2022

Except for GAT, we rely on type_alias_impl_trait feature, and it's hard to get rid of it...

@jklop123
Copy link

With async_fn_in_trait, return_position_impl_trait_in_trait has merged into the stable version (1.75), perhaps a non-GAT implementation based on the stable version will become possible.

@ihciah
Copy link
Member

ihciah commented Nov 6, 2023

With async_fn_in_trait, return_position_impl_trait_in_trait has merged into the stable version (1.75), perhaps a non-GAT implementation based on the stable version will become possible.

Yes it is. It would become simpler to write trait and impl, but it may causes break changes. Also I don't know if there would be overhead when replace code like this:

type RetFut = impl Future<..>;
fn demo(&self, num: i32) -> Self::RetFut {...}
fn demo2(&self, num: i32) -> Self::RetFut {
    let num = nun + 1;
    self.demo(num)
}

to

async fn demo(&self, num: i32) -> xxx {...}
async fn demo2(&self, num: i32) -> xxx {
    let num = nun + 1;
    self.demo(num).await
}

If no overhead, I think it will be better to use the new style.

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

Successfully merging a pull request may close this issue.

3 participants