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

Target stable Rust #242

Closed
vorot93 opened this issue Jul 16, 2019 · 6 comments · Fixed by #267
Closed

Target stable Rust #242

vorot93 opened this issue Jul 16, 2019 · 6 comments · Fixed by #267
Labels

Comments

@vorot93
Copy link
Contributor

vorot93 commented Jul 16, 2019

This is a full list of feature flags used by tarpc.

Now that Futures 1.0 have arrived I believe we can start dropping them one by one until tarpc works on stable Rust.

Continued from #131.

This was referenced Jul 16, 2019
@tikue
Copy link
Collaborator

tikue commented Jul 16, 2019

Probably the hardest dependencies at this point are:

  1. async_await -- this can't be removed, but it will be stabilized soon (I think).
  2. arbitrary_self_types -- required to implement futures by hand. I suspect it may be reaching stabilization soon.
  3. proc_macro_hygiene -- required for the service! macro to generate traits etc. I have no idea how soon it will be stabilized.

Incidentally, these are also the three features that tarpc users have to enable.

@tikue
Copy link
Collaborator

tikue commented Jul 16, 2019

  1. external_doc -- can be replaced by copying the readme into lib.rs. It will mean the readme is subject to version skew, and we should investigate other solutions (I know some exist in the ecosystem).
  2. weak_counts -- used by server::ChannelFilter and requires some investigation to remove.
  3. non_exhaustive -- can replace with a doc-hidden NonExhaustive field / variant.
  4. trait_alias -- used to define Transport; can be replaced by a real trait and a blanket impl.

@tikue tikue added the Cleanup label Jul 16, 2019
@vorot93
Copy link
Contributor Author

vorot93 commented Jul 17, 2019

Regarding async_await: we should be able to rewrite async blocks using combinators, shouldn't we? Not a priority and decidedly not pretty but not a blocker if other nightly features get replaced before 1.38.

@tikue
Copy link
Collaborator

tikue commented Jul 17, 2019

That's true, but I'd rather only do that as a last resort (i.e. if usage of all other unstable features were removed and a user was asking for it immediately). It's hugely more maintainable to use async/await. And it's only one release away :)

@tikue
Copy link
Collaborator

tikue commented Jul 19, 2019

It was actually quite easy to get rid of arbitrary_self_types! I didn't realize they'd stabilized the specific usage of Pin<Self> as a receiver.

@vorot93
Copy link
Contributor Author

vorot93 commented Oct 1, 2019

async-await has hit beta, it's time to cross off the remaining feature flags asap.

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

Successfully merging a pull request may close this issue.

2 participants