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

TryStream and compiler “limitations” #2508

Open
steffahn opened this issue Oct 13, 2021 · 5 comments
Open

TryStream and compiler “limitations” #2508

steffahn opened this issue Oct 13, 2021 · 5 comments

Comments

@steffahn
Copy link
Member

Reading

/// Poll this `TryStream` as if it were a `Stream`.
///
/// This method is a stopgap for a compiler limitation that prevents us from
/// directly inheriting from the `Stream` trait; in the future it won't be
/// needed.
fn try_poll_next(
self: Pin<&mut Self>,
cx: &mut Context<'_>,
) -> Poll<Option<Result<Self::Ok, Self::Error>>>;

I’m wondering: what’s those limitations?

Trying something like b7f417d seems to work without problems.

@taiki-e
Copy link
Member

taiki-e commented Oct 13, 2021

IIRC limitation is: #1776 (comment)

However, a recent compiler change (probably in 1.52) may have fixed this.

@steffahn
Copy link
Member Author

Okay; even on older versions it still seems to work by means of writing

pub trait TryStream: Stream<Item = Result<<Self as TryStream>::Ok, <Self as TryStream>::Error>> {
    /// The type of successful values yielded by this future
    type Ok;

    /// The type of failures yielded by this future
    type Error;
}

instead of

pub trait TryStream: Stream<Item = Result<Self::Ok, Self::Error>> {
    /// The type of successful values yielded by this future
    type Ok;

    /// The type of failures yielded by this future
    type Error;
}

but perhaps that workaround wasn’t known by the author of the comment.

@steffahn
Copy link
Member Author

steffahn commented Oct 13, 2021

Nevermind, even that more explicit version doesn’t work before 1.46; the TryStream trait may be older than that? Edit: Yes it is.

@steffahn
Copy link
Member Author

…and I see a MSRV of 1.41 for futures if I’m interpreting that correctly. At least the comment should be updated to reflect that current Rust versions don’t have the limitation anymore. What’s the MSRV policy here? At least in an eventual 0.4 release that supertrait bound should probably be introduced; and removing the method requires a new semver-major version anyways.

@taiki-e
Copy link
Member

taiki-e commented Oct 13, 2021

The current MSRV for futures/futures-util is 1.41, and for some crates, such as futures-core, which provides only traits, the MSRV is 1.36.

The MSRV policy for futures/futures-util is basically "whatever popular distros support". (#2405)

In 0.4, the trait aliases will be moved to futures-util (#2207 (comment)), so it is okay to change the MSRV of futures-util 0.4 to 1.46 and remove the try_poll_next method.

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

No branches or pull requests

2 participants