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

Move some net2 functionality into libstd #1461

Merged
merged 1 commit into from Feb 18, 2016

Conversation

Projects
None yet
5 participants
@sfackler
Member

sfackler commented Jan 13, 2016

@aturon aturon added the I-nominated label Feb 10, 2016

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Feb 11, 2016

🔔 This RFC is now entering its week-long final comment period 🔔

Please don't everyone comment all at once!

More seriously, though, the libs team is interested specifically in diving into the landing strategy for this in libstd, either:

  • This new functionality lands insta-stable
  • The new functionality lands as an unstable extension trait

My own personal opinion is that we should land these as insta-stable. The APIs have been vetted in net2-rs for quite some time now, and I don't think we'd really gain all that much more use through another round of FCP for the APIs.

Curious what others think though!

@briansmith

This comment has been minimized.

briansmith commented Feb 13, 2016

I don't think these should be added via traits. Over time, the standard library would become a ridiculous mess of such traits as new functionality is added, if it were to follow that pattern.

@sfackler

This comment has been minimized.

Member

sfackler commented Feb 13, 2016

The traits would only exist until the methods were stabilized.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Feb 18, 2016

The libs team discussed this during triage yesterday and the conclusion was to merge this RFC adding these methods as insta-stable. Thanks for the RFC @sfackler!

@sfackler

This comment has been minimized.

Member

sfackler commented Feb 18, 2016

We're going to hold off on the implementation until just after the next release to allow for the longest possible time before these hit a stable release and are locked in forever.

@tshepang

This comment has been minimized.

Contributor

tshepang commented Feb 18, 2016

How about simply not making them insta-stable? That to me sounds better than delaying the landing.

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