Survey of unstable standard library features

libs
1

The standard library has a number of unstable features. I had a feeling that some of them have been there for a long time without really being blocked on anything. To find out, I went through all of them and checked.

for i in $(rg 'issue *= *"[^"]*"' -o --no-filename|cut -d'"' -f2|sort -un);
  echo "#$i $(curl -s https://api.github.com/repos/rust-lang/rust/issues/$i|jq .title -r)"

This script finds #[unstable] attributes in the repository and fetches the title of each tracking issue. As of Rust commit a7170b0412d1baa4e30cb31d1ea326617021f086 (2018-03-16), there are about a hundred of them. Classification from there is manual, I may have missed or misjudged some things.

Status unclear based on only a quick look at tracking issues

If you know what needs to happen next for any of these, please write a summary comment in the corresponding issue.

  • #27779 Tracking issue for placement new
  • #29625 Tracking issue for Fn traits (unboxed_closures feature)
  • #30172 Implement placement-in protocol for relevant data structures
  • #33577 Tracking issue for std::sync::Once poisoning
  • #42327 Tracking issue for ops::Try (try_trait feature)
  • #48711 Tracking issue for std::process::ExitCode (feature process_exitcode_placeholder)

Stabilization FCP complete, needs a PR

Help wanted!

  • #27726 Tracking issue for access to Formatter alignment

  • #35118 Tracking issue for 128-bit integer support (RFC 1504)

    mark-i-m volunteered to make a PR

  • #40895 Tracking issue for the FromUtf8Error::as_bytes

  • #42781 Tracking issue for std::io::Take::set_limit (take_set_limit)

  • #43874 Tracking issue for String::retain

  • #44643 Tracking issue for String::splice

FCP now proposed to stabilize :tada:

These did seem not to be blocked on anything. FCP all the things!

  • #13226 Tracking Issue: fetch_nand
  • #27741 Tracking issue for step_by stabilization
  • #27745 Tracking issue for type_id stabilization
  • #31100 BufReader should provide a way to seek without dumping the buffer
  • #39480 Tracking issue for (DoubleEnded)?Iterator::rfind
  • #40062 Tracking issue for Vec::remove_item
  • #41020 Add methods [T]::rsplit and [T]::rsplit_mut
  • #41263 Tracking issue for ToOwned::clone_into (toowned_clone_into)
  • #42818 Tracking issue for ptr::swap_nonoverlapping (library feature swap_nonoverlapping)
  • #43570 Tracking issue for RefCell::{replace, swap}
  • #43751 Tracking issue for mem::unreachable
  • #44030 Tracking issue for [T]::swap_with_slice feature
  • #44324 Entry APIs should have or_default for V: Default
  • #44400 Consider adding a from_micros for std::time::Duration
  • #44608 Tracking issue for Rc::downcast (rc_downcast feature)
  • #44705 Tracking issue for DoubleEndedIterator::rfold (feature iter_rfold)
  • #44971 getpid function
  • #45323 BufReader should have an is_empty() method
  • #45594 Tracking issue for Iterator::try_fold and try_rfold (feature iterator_try_fold)
  • #45703 Tracking issue for slice::from_ref and slice::from_ref_mut
  • #45860 Tracking issue for Option::filter (feature option_filter)
  • #46104 Tracking issue for process::parent_id
  • #46344 Tracking issue for HashMap::remove_entry
  • #46507 Duration should have consistent methods for all units

Looks good to me to stabilize after some more time in Nightly

  • #47336 Tracking issue for Box::into_raw_non_null
  • #47338 Tracking Issue for Result and Option Conversion
  • #47653 Tracking issue for std::ptr::NonNull::cast
  • #47960 CondVar wait functions accepting a closure
  • #48043 Tracking issue for RFC #2116: fallible collection allocation
  • #48111 Tracking issue for Range[Inclusive]::is_empty (feature range_is_empty)
  • #48169 Tracking issue for std::iter::repeat_with
  • #48213 Tracking issue for Iterator::flatten
  • #48320 Tracking issue for non-panicking pow
  • #48581 Tracking issue for std::path::Path::ancestors
  • #48763 Tracking issue for reversing the bit pattern in an integer

Making progress

Seems close to stabilization-ready, needs some more work

  • #27709 Tracking issue for Ipv{4,6}Addr convenience methods

    Needs audit of IETF RFCs and IANA publications to double-check semantics

  • #27747 Tracking issue for slice_concat_ext stabilization

    Replace with inherent methods?

  • #30877 Tracking issue for RangeArgument

    Move it and Bounds to libcore: https://github.com/rust-lang/rust/issues/30877#issuecomment-330014651

  • #35729 Tracking issue for the SliceIndex trait

    Try to replace range impls with one generic impl on T: RangeArgument?

  • #41758 Tracking issue for Vec::resize_default

    Team decision replace with resize_with taking a callback. Docs should include a .resize_with(n, Default::default) example.

  • #44286 Allow a HashMap and BTreeMap entry to be replaced.

    I don’t quite understand the need for this, waiting on reply from author

Needs design decision

  • #27791 Tracking issue for str escaping

    API of the returned types. (Display? Iterator? Both?)

  • #35428 Add is_empty function to ExactSizeIterator

    What trait, if any (v.s. inherent methods), should this be on?

  • #37572 Tracking issue for TrustedLen (trusted_len)

    Rename?

  • #41079 Tracking issue for ptr::offset_to

    What to do on non-multiple of size_of

  • #43244 Tracking issue for Vec::drain_filter and LinkedList::drain_filter

    Taking a range? Naming?

  • #44582 Tracking issue for IP constructors

    Changing to associated const items requires a bunch of things to be const fn

  • #46588 Tracking issue for std::fs::read, read_string, and write

    Naming

  • #47115 Tracking issue for exact_chunks/_mut; slice chunks with exact size

    Ignore extra items, or panic if any?

  • #49022 Tracking issue for RFC 1980, start and end fields of RangeInclusive

    Public fields v.s. getter methods

To deprecate?

  • #27800 Tracking issue for channel selection

    De-facto deprecated. Servo might be the last user. Can hopefully move to crossbeam-channel soon.

  • #27802 Tracking issue for Read::chars

    Design / trade-off space is large. Maybe better served outside of std?

  • #33906 Tracking issue: UTF-8 decoder in libcore

    core::str::from_utf8 may be sufficient and sometimes better

Likely needs non-trivial implementation or design work

  • #27721 Tracking issue for string patterns

    https://github.com/rust-lang/rfcs/pull/2295 “Extend Pattern API to OsStr” proposes changes

  • #27794 Tracking issue for extra linked list methods

    A full cursor API is preferred

  • #27812 Tracking issue for crates that are compiler dependencies

    Perma-unstable, but may want some mechanism other than #[unstable] to make unavailable to users.

  • #28796 Tracking issue for FnBox()

    Desire to stabilize and later deprecated when Box can be made to work, but concern that this would cause trait coherence issues.

  • #32311 Tracking issue for Range*::contains

    https://github.com/rust-lang/rust/issues/32311#issuecomment-312388435

  • #32837 Pluggable panic implementations (tracking issue for RFC 1513)

  • #32838 Allocator traits and std::heap

  • #38356 Tracking issue for RFC 1566: Procedural macros

  • #42168 Tracking issue for step_trait stabilization

  • #42788 Tracking issue for Read::initializer

    Alex “not sold” on the current design. I tend to agree but don’t have a proposal at the moment

  • #43122 Tracking issue for RFC 2033: Experimentally add coroutines to Rust

  • #43301 Tracking issue for RFC 1937: ? in main

  • #44488 Tracking issue for RFC 2043: Add align_offset intrinsic and [T]::align_to function

    align_to is not implemented yet

  • #44489 Tracking issue for RFC 2070: stable mechanism to specify the behavior of panic! in no-std applications

  • #46316 API convention for blocking-, timeout-, and/or deadline-related functions

    Only one new method out of many discussed (proposed?) is implemented.

  • #48556 Tracking issue for stable SIMD in Rust

Waiting on other work

  • #27778 Tracking issue for FixedSizeArray trait

    Unnecessary with const generics, to be deprecated

  • #27751 Tracking issue for raw stabilization (raw::TraitObject)

    Only pub struct TraitObject { pub data: *mut (), pub vtable: *mut () } Likely better as conversion APIs Design likely affected by a potential “Custom DST” RFC

  • #27732 Tracking issue for DST coercions (coerce_unsized, unsize) stabilization

    Awaiting a “Custom DST” RFC?

  • #27783 Tracking issue for location of facade crates

    A vision for portability in Rust proposes undoing the facade

  • #29599 Tracking issue for concat_idents

    Useless without eager macro expansion (which needs an RFC)

  • #32110 Tracking issue for libcore prelude traits

    A vision for portability in Rust proposes undoing the facade

  • #32976 Tracking issue for adding more atomic integer types

    Portability lint?

Deprecated + unstable (to remove)

Search false positives (found in tests)

  • #0
  • #1
  • #2
  • #18199 Warnings caused by examples in libstd should fail the doc tests
  • #27759 rustdoc unstable should show feature name and issue
  • #32374 Show unstable status for deprecated items
  • #38412 internal compiler error: …/src/librustc/middle/stability.rs:516: encountered unmarked API
  • #1234567890
75 Likes
2

Awesome work, thank you for doing this!

1 Like
3

First, @SimonSapin, thanks for doing this! really, it was hard work, and most of these issues needed a push, and putting things into FCP is really a good way to push this.

Second, some of the issues in FCP feel like “design by PR”. Someone added an issue to rust-lang/rust, someone submitted a PR to address it, some people mentioned issues, suggested better designs, and in most cases nobody either cared to even answer these comments nor to submit follow up PRs.

So the grep “unstable” to FCP approach gives me the feeling that we are stabilizing things just to shorten a checklist that can be shown to managers, which makes me a bit uncomfortable.

At least, the proposal for FCP should come with a comment explaining exactly what will be stabilized. Often, the only way to know is to search for the PRs that actually implemented stuff and try to extract rationale from that, and then, having to skim through a github issue full of unanswered feedback. IMO such a summarizing comment should go beyond “what will be stabilized” and also summarize the discussion: open issues, alternatives considered, rationale, and maybe a snippet for the docs team so that they know what to do: are the docs already upstream? if so where? should they be reviewed? etc.

Two examples are Vec::remove_items method and the step_trait. I’ve read the issue, tried to follow PRs, and have no idea what is actually going to be stabilized, which work was done here, what happened with the many remaining open design issues most of them seem to never been neither addressed nor acknowledge beyond a couple of “thumbs up” on github here and there.

So maybe this is a process issue: @aturon, for rust-lang/rfcs discussion what’s being put in FCP is the RFC in the repo, but for tracking issues in rust-lang/rust, it is often impossible to know what the FCP is actually about because things change a lot from what was proposed in an RFC, if there ever was an RFC at all. I am not saying these things need a second RFC, but a summarizing comment should be the bare minimum IMO.

In any case, @SimonSapin, thanks again for doing this. All of these issues really needed a push. Doing the original design and implementation is fun, but writing docs, answering to feedback, and moving almost finished features into a finished state is boring work that many don’t like to do. So things remain in the “almost finished” limbo forever. I just wanted to point out that there is a difference between “almost finished” and “finished”, and that it is hard to tell in which states some of the issues in FCP actually are.

4 Likes
4

These are all fair points.

For what it’s worth my “day job” is Servo, working on the standard library is only tangentially part of it, and this particular checklist probably doesn’t make much of a difference to my manager :slight_smile: My motivation for doing this is having had my own proposals be accepted, and then stay in unstable limbo for many months for no particular reason.

I did not set out to FCP everything, I wanted to get an idea of what the next step is for each feature and only proposed FCP when that seemed to be the appropriate next step. I didn’t realize when I started there would be so many.

I did try to look for unresolved issues on each feature before proposing FCP, but I may have missed some things. If so I’m sorry, please make use of this comment period to point out issues and questions and we can pause the process until they are resolved. Though when a proposal is “we should also do X” I’ve considered it not a blocking issue but something that can be submitted separately by whoever wants it enough to write the PR.

I agree that FCP to stabilize is the time to review more carefully, and perhaps tweak/change, things that did not go through the RFC process. I think that explaining what is being tracked is the role of the original message of a tracking issue. In some cases (including Vec::remove_items and Iterator::step_by) I’ve edited that message to reflect the current status. Often I haven’t felt the need to repeat every detail that is already documented under https://doc.rust-lang.org/nightly/std/, but I don’t mind doing more of that if it helps.

5 Likes
5

Though when a proposal is “we should also do X” I’ve considered it not a blocking issue but something that can be submitted separately by whoever wants it enough to write the PR.

I agree that these are non-blocking.

I agree that FCP to stabilize is the time to review more carefully, and perhaps tweak/change, things that did not go through the RFC process. I think that explaining what is being tracked is the role of the original message of a tracking issue. In some cases (including Vec::remove_items and Iterator::step_by) I’ve edited that message to reflect the current status. Often I haven’t felt the need to repeat every detail that is already documented under std - Rust, but I don’t mind doing more of that if it helps.

I tend to discover issues when they get into FCP because when that happens these issues get a lot of advertisement. My comment above was written in the heat of frustration, in particular the "manager" thing was completely out of tone, so my apologies for that. Your summary comment in the step_by tracking issue is great and basically resolved all of the questions I had.

I think that adding a summarizing comment of the discussion in the issue with an exact description (or a link to the docs or something) of what is being stabilized, the summary of the discussion so far, and the rationale for going into FCP is very helpful. I don't think it is necessary to completely edit the tracking issue with everything that happened, those who care of the history can go through all of it. But a link to the comment arguing for the FCP at the very top would at least be good enough for me, for example, something like:

Final Comment Period: this comment contains a summary of the discussion before the start of the final comment period and the rationale for moving into it.

6

I suggested to not stabilize this unless there's an efficient implementation of it. And currently there isn't. A missing efficient implementation could mean that the design is not good enough.

7

This really should go into respective tracking issues’ threads rather than here, but:

You’re probably thinking of ranges. As noted in the tracking issue, this the iterator wrapper based on nth. It may or may not be the right solution for ranges, which might end up with dedicated methods/types. The tracking issue for range iteration and the Step trait is https://github.com/rust-lang/rust/issues/42168. FCP for the Step trait is not proposed at this time.

8

What about non_ascii_idents? They are also unstable: https://github.com/rust-lang/rust/issues/28979

9

This time around I only focused on unstable library features. (There’s enough of them already.) But yeah it would be good to do something similar for language features.

For this one specifically, IIRC there’s uncertainty about what characters exactly should be allowed or not. Research needs to be done about what other programming languages that have a similar feature do there, why they made those choices, and what are the trade-offs. (We already know they don’t all do exactly the same thing.)

1 Like
10

I’d like to mention https://github.com/rust-lang/rust/issues/49359 which I forgot to create a tracking issue for until now.

11

Also not a standard library feature :slight_smile:

1 Like
12

Whoops. Didn’t realize it’s libstd specific. Sorry

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.