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

Tracking Issue for future readiness functions #70921

Closed
2 tasks done
yoshuawuyts opened this issue Apr 8, 2020 · 3 comments
Closed
2 tasks done

Tracking Issue for future readiness functions #70921

yoshuawuyts opened this issue Apr 8, 2020 · 3 comments
Labels
A-async-await AsyncAwait-Triaged B-unstable C-tracking-issue Libs-Tracked T-libs-api

Comments

@yoshuawuyts
Copy link
Member

yoshuawuyts commented Apr 8, 2020

This is a tracking issue for core::future::{pending,ready}.
The feature gate for the issue is #![feature(future_readiness_fns)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

Implementation history

@yoshuawuyts yoshuawuyts added the C-tracking-issue label Apr 8, 2020
@jonas-schievink jonas-schievink added B-unstable T-libs-api labels Apr 8, 2020
@KodrAus KodrAus added A-async-await Libs-Tracked labels Jul 29, 2020
@tmandry tmandry added the AsyncAwait-Triaged label Aug 4, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Sep 12, 2020
…ess-fns, r=sfackler

Stabilize core::future::{pending,ready}

This PR stabilizes `core::future::{pending,ready}`, tracking issue rust-lang#70921.

## Motivation

These functions have been on nightly for three months now, and have lived as part of the futures ecosystem for several years. In that time these functions have undergone several iterations, with [the `async-std` impls](https://docs.rs/async-std/1.6.2/async_std/future/index.html) probably diverging the most (using `async fn`, which in hindsight was a mistake).

It seems the space around these functions has been _thoroughly_ explored over the last couple of years, and the ecosystem has settled on the current shape of the functions. It seems highly unlikely we'd want to make any further changes to these functions, so I propose we stabilize.

## Implementation notes

This stabilization PR was fairly straightforward; this feature has already thoroughly been reviewed by the libs team already in rust-lang#70834. So all this PR does is remove the feature gate.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 12, 2020
…s-fns, r=sfackler

Stabilize core::future::{pending,ready}

This PR stabilizes `core::future::{pending,ready}`, tracking issue rust-lang#70921.

## Motivation

These functions have been on nightly for three months now, and have lived as part of the futures ecosystem for several years. In that time these functions have undergone several iterations, with [the `async-std` impls](https://docs.rs/async-std/1.6.2/async_std/future/index.html) probably diverging the most (using `async fn`, which in hindsight was a mistake).

It seems the space around these functions has been _thoroughly_ explored over the last couple of years, and the ecosystem has settled on the current shape of the functions. It seems highly unlikely we'd want to make any further changes to these functions, so I propose we stabilize.

## Implementation notes

This stabilization PR was fairly straightforward; this feature has already thoroughly been reviewed by the libs team already in rust-lang#70834. So all this PR does is remove the feature gate.
tmandry added a commit to tmandry/rust that referenced this issue Sep 16, 2020
…y-stabilization-label, r=Dylan-DPC

Fix stabilization marker for future_readiness_fns

Updated the rustc version in which this will be stabilized from `1.47.0 -> 1.48.0`. Fixes rust-lang#74328 (comment). Ref rust-lang#70921.

r? @Dylan-DPC
@petertodd
Copy link
Contributor

petertodd commented Nov 16, 2020

Currently we have:

pub struct Pending<T> {
    _data: marker::PhantomData<T>,
}

That means Pending<T> has dropcheck behavior as though it owns a T value, which it doesn't. Should we instead change it to:

pub struct Pending<T> {
    _data: marker::PhantomData<fn() -> T>,
}

I believe that is a strict improvement without any compatibility issues, as the variance is the same.

@yoshuawuyts
Copy link
Member Author

yoshuawuyts commented Nov 19, 2020

@petertodd this was discussed in #70834 and decided against. Some of the conversation happened in code comments, so it may require expanding some closed comments to get the full conversation.

With the release of 1.48 these PRs have been stabilized, so it's probably time to close! Any conversation about these APIs should probably happen in their own PRs.

@petertodd
Copy link
Contributor

petertodd commented Nov 20, 2020

stmpjmpr added a commit to pubnub/rust that referenced this issue Feb 25, 2022
* Changed `assert_eq!` tests to `assert!` to fix the build.
* Added semicolons to last line of functions to make pedantic clippy happy.
* Changed explicit impl of Default for timetoken.rs to be derived instead.
* Refactored assertion in subscription.rs to make clippy happy.
* Allowing unknown lints so that the build can pass. Older versions use `broken_intra_doc_links` and newer ones use `rustdoc::broken_intra_doc_links`, so the build fails on one or the other, so allowing unknown lints for now.
* Formatting to make the linter happy.
* Allowing unused async, because it's required for `ControlOutcome`, but Clippy insists it isn't.
* Resolving issues detected by Clippy: "expression borrows a reference...that is immediately dereferenced by the compiler"
* Bumping minimum version to Rust 1.49.0 due to:
- rust-lang/rust#55002
- rust-lang/rust#70921
* Added TODOs to remove linter allows for unknown, renamed, and removed lints when Rust 1.59.0 becomes minimum version.
* Added todo where the default UUID behavior is specified.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await AsyncAwait-Triaged B-unstable C-tracking-issue Libs-Tracked T-libs-api
Projects
None yet
Development

No branches or pull requests

5 participants