Skip to content

Tracking Issue for future readiness functions #70921

Description

@yoshuawuyts

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

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Apr 8, 2020
  2. added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    T-libs-api[DEPRECATED; DO NOT USE]
    on Apr 8, 2020
  3. added
    AsyncAwait-TriagedAsync-await issues that have been triaged during a working group meeting.
    on Aug 4, 2020
  4. added a commit that references this issue on Sep 12, 2020
  5. added a commit that references this issue on Sep 12, 2020
  6. added a commit that references this issue on Sep 16, 2020
  7. petertodd commented on Nov 16, 2020

    @petertodd
    Contributor

    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.

  8. yoshuawuyts commented on Nov 19, 2020

    @yoshuawuyts
    MemberAuthor

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

  9. petertodd commented on Nov 20, 2020

    @petertodd
    Contributor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-async-awaitArea: Async & AwaitAsyncAwait-TriagedAsync-await issues that have been triaged during a working group meeting.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.T-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions