# Survey of unstable standard library features

**URL:** <https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075>\
**Category:** libs\
**Created:** [March 17, 2018, 7:09pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075 "2018-03-17T19:09:41Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![SimonSapin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/simonsapin/32/3158_2.png) [@SimonSapin](https://internals.rust-lang.org/u/SimonSapin)\
**Post date:** [March 17, 2018, 7:09pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/1 "2018-03-17T19:09:41Z")

</div>

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.

```rust
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](https://github.com/rust-lang/rust/issues/27779) Tracking issue for placement new
- [#29625](https://github.com/rust-lang/rust/issues/29625) Tracking issue for Fn traits (`unboxed_closures` feature)
- [#30172](https://github.com/rust-lang/rust/issues/30172) Implement placement-in protocol for relevant data structures
- [#33577](https://github.com/rust-lang/rust/issues/33577) Tracking issue for std::sync::Once poisoning
- [#42327](https://github.com/rust-lang/rust/issues/42327) Tracking issue for `ops::Try` (`try_trait` feature)
- [#48711](https://github.com/rust-lang/rust/issues/48711) Tracking issue for std::process::ExitCode (feature process\_exitcode\_placeholder)

## Stabilization FCP complete, needs a PR

Help wanted!

- [#27726](https://github.com/rust-lang/rust/issues/27726) Tracking issue for access to Formatter alignment

- [#35118](https://github.com/rust-lang/rust/issues/35118) Tracking issue for 128-bit integer support (RFC 1504)

- [#40895](https://github.com/rust-lang/rust/issues/40895) Tracking issue for the FromUtf8Error::as\_bytes

- [#42781](https://github.com/rust-lang/rust/issues/42781) Tracking issue for std::io::Take::set\_limit (take\_set\_limit)

- [#43874](https://github.com/rust-lang/rust/issues/43874) Tracking issue for `String::retain`

- [#44643](https://github.com/rust-lang/rust/issues/44643) Tracking issue for String::splice

## FCP now proposed to stabilize 🎉

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

- [#13226](https://github.com/rust-lang/rust/issues/13226) Tracking Issue: fetch\_nand
- [#27741](https://github.com/rust-lang/rust/issues/27741) Tracking issue for `step_by` stabilization
- [#27745](https://github.com/rust-lang/rust/issues/27745) Tracking issue for type\_id stabilization
- [#31100](https://github.com/rust-lang/rust/issues/31100) BufReader should provide a way to seek without dumping the buffer
- [#39480](https://github.com/rust-lang/rust/issues/39480) Tracking issue for (DoubleEnded)?Iterator::rfind
- [#40062](https://github.com/rust-lang/rust/issues/40062) Tracking issue for Vec::remove\_item
- [#41020](https://github.com/rust-lang/rust/issues/41020) Add methods `[T]::rsplit` and `[T]::rsplit_mut`
- [#41263](https://github.com/rust-lang/rust/issues/41263) Tracking issue for `ToOwned::clone_into` (`toowned_clone_into`)
- [#42818](https://github.com/rust-lang/rust/issues/42818) Tracking issue for ptr::swap\_nonoverlapping (library feature swap\_nonoverlapping)
- [#43570](https://github.com/rust-lang/rust/issues/43570) Tracking issue for RefCell::{replace, swap}
- [#43751](https://github.com/rust-lang/rust/issues/43751) Tracking issue for `mem::unreachable`
- [#44030](https://github.com/rust-lang/rust/issues/44030) Tracking issue for [T]::swap\_with\_slice feature
- [#44324](https://github.com/rust-lang/rust/issues/44324) Entry APIs should have or\_default for V: Default
- [#44400](https://github.com/rust-lang/rust/issues/44400) Consider adding a from\_micros for `std::time::Duration`
- [#44608](https://github.com/rust-lang/rust/issues/44608) Tracking issue for Rc::downcast (`rc_downcast` feature)
- [#44705](https://github.com/rust-lang/rust/issues/44705) Tracking issue for DoubleEndedIterator::rfold (feature `iter_rfold`)
- [#44971](https://github.com/rust-lang/rust/issues/44971) getpid function
- [#45323](https://github.com/rust-lang/rust/issues/45323) BufReader should have an is\_empty() method
- [#45594](https://github.com/rust-lang/rust/issues/45594) Tracking issue for Iterator::try\_fold and try\_rfold (feature iterator\_try\_fold)
- [#45703](https://github.com/rust-lang/rust/issues/45703) Tracking issue for `slice::from_ref` and `slice::from_ref_mut`
- [#45860](https://github.com/rust-lang/rust/issues/45860) Tracking issue for Option::filter (feature `option_filter`)
- [#46104](https://github.com/rust-lang/rust/issues/46104) Tracking issue for process::parent\_id
- [#46344](https://github.com/rust-lang/rust/issues/46344) Tracking issue for HashMap::remove\_entry
- [#46507](https://github.com/rust-lang/rust/issues/46507) Duration should have consistent methods for all units

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

- [#47336](https://github.com/rust-lang/rust/issues/47336) Tracking issue for Box::into\_raw\_non\_null
- [#47338](https://github.com/rust-lang/rust/issues/47338) Tracking Issue for Result and Option Conversion
- [#47653](https://github.com/rust-lang/rust/issues/47653) Tracking issue for std::ptr::NonNull::cast
- [#47960](https://github.com/rust-lang/rust/issues/47960) CondVar wait functions accepting a closure
- [#48043](https://github.com/rust-lang/rust/issues/48043) Tracking issue for RFC #2116: fallible collection allocation
- [#48111](https://github.com/rust-lang/rust/issues/48111) Tracking issue for Range[Inclusive]::is\_empty (feature range\_is\_empty)
- [#48169](https://github.com/rust-lang/rust/issues/48169) Tracking issue for std::iter::repeat\_with
- [#48213](https://github.com/rust-lang/rust/issues/48213) Tracking issue for Iterator::flatten
- [#48320](https://github.com/rust-lang/rust/issues/48320) Tracking issue for non-panicking pow
- [#48581](https://github.com/rust-lang/rust/issues/48581) Tracking issue for std::path::Path::ancestors
- [#48763](https://github.com/rust-lang/rust/issues/48763) Tracking issue for reversing the bit pattern in an integer

## Making progress

- [#27730](https://github.com/rust-lang/rust/issues/27730) Tracking issue for `NonZero`/`Unique`/`Shared` stabilization

- [#33417](https://github.com/rust-lang/rust/issues/33417) Tracking issue for TryFrom/TryInto traits

## Seems close to stabilization-ready, needs some more work

- [#27709](https://github.com/rust-lang/rust/issues/27709) Tracking issue for Ipv{4,6}Addr convenience methods

- [#27747](https://github.com/rust-lang/rust/issues/27747) Tracking issue for `slice_concat_ext` stabilization

- [#30877](https://github.com/rust-lang/rust/issues/30877) Tracking issue for RangeArgument

- [#35729](https://github.com/rust-lang/rust/issues/35729) Tracking issue for the `SliceIndex` trait

- [#41758](https://github.com/rust-lang/rust/issues/41758) Tracking issue for Vec::resize\_default

- [#44286](https://github.com/rust-lang/rust/issues/44286) Allow a `HashMap` and `BTreeMap` entry to be replaced.

## Needs design decision

- [#27791](https://github.com/rust-lang/rust/issues/27791) Tracking issue for str escaping

- [#35428](https://github.com/rust-lang/rust/issues/35428) Add `is_empty` function to `ExactSizeIterator`

- [#37572](https://github.com/rust-lang/rust/issues/37572) Tracking issue for TrustedLen (`trusted_len`)

- [#41079](https://github.com/rust-lang/rust/issues/41079) Tracking issue for ptr::offset\_to

- [#43244](https://github.com/rust-lang/rust/issues/43244) Tracking issue for Vec::drain\_filter and LinkedList::drain\_filter

- [#44582](https://github.com/rust-lang/rust/issues/44582) Tracking issue for IP constructors

- [#46588](https://github.com/rust-lang/rust/issues/46588) Tracking issue for std::fs::read, read\_string, and write

- [#47115](https://github.com/rust-lang/rust/issues/47115) Tracking issue for exact\_chunks/\_mut; slice chunks with exact size

- [#49022](https://github.com/rust-lang/rust/issues/49022) Tracking issue for RFC 1980, `start` and `end` fields of RangeInclusive

## To deprecate?

- [#27800](https://github.com/rust-lang/rust/issues/27800) Tracking issue for channel selection

- [#27802](https://github.com/rust-lang/rust/issues/27802) Tracking issue for Read::chars

- [#33906](https://github.com/rust-lang/rust/issues/33906) Tracking issue: UTF-8 decoder in libcore

## Likely needs non-trivial implementation or design work

- [#27721](https://github.com/rust-lang/rust/issues/27721) Tracking issue for string patterns

- [#27794](https://github.com/rust-lang/rust/issues/27794) Tracking issue for extra linked list methods

- [#27812](https://github.com/rust-lang/rust/issues/27812) Tracking issue for crates that are compiler dependencies

- [#28796](https://github.com/rust-lang/rust/issues/28796) Tracking issue for FnBox()

- [#32311](https://github.com/rust-lang/rust/issues/32311) Tracking issue for Range\*::contains

- [#32837](https://github.com/rust-lang/rust/issues/32837) Pluggable panic implementations (tracking issue for RFC 1513)

- [#32838](https://github.com/rust-lang/rust/issues/32838) Allocator traits and std::heap

- [#38356](https://github.com/rust-lang/rust/issues/38356) Tracking issue for RFC 1566: Procedural macros

- [#42168](https://github.com/rust-lang/rust/issues/42168) Tracking issue for `step_trait` stabilization

- [#42788](https://github.com/rust-lang/rust/issues/42788) Tracking issue for `Read::initializer`

- [#43122](https://github.com/rust-lang/rust/issues/43122) Tracking issue for RFC 2033: Experimentally add coroutines to Rust

- [#43301](https://github.com/rust-lang/rust/issues/43301) Tracking issue for RFC 1937: `?` in `main`

- [#44488](https://github.com/rust-lang/rust/issues/44488) Tracking issue for RFC 2043: Add `align_offset` intrinsic and `[T]::align_to` function

- [#44489](https://github.com/rust-lang/rust/issues/44489) Tracking issue for RFC 2070: stable mechanism to specify the behavior of panic! in no-std applications

- [#46316](https://github.com/rust-lang/rust/issues/46316) API convention for blocking-, timeout-, and/or deadline-related functions

- [#48556](https://github.com/rust-lang/rust/issues/48556) Tracking issue for stable SIMD in Rust

## Waiting on other work

- [#27778](https://github.com/rust-lang/rust/issues/27778) Tracking issue for FixedSizeArray trait

- [#27751](https://github.com/rust-lang/rust/issues/27751) Tracking issue for `raw` stabilization (`raw::TraitObject`)

- [#27732](https://github.com/rust-lang/rust/issues/27732) Tracking issue for DST coercions (coerce\_unsized, unsize) stabilization

- [#27783](https://github.com/rust-lang/rust/issues/27783) Tracking issue for location of facade crates

- [#29599](https://github.com/rust-lang/rust/issues/29599) Tracking issue for `concat_idents`

- [#32110](https://github.com/rust-lang/rust/issues/32110) Tracking issue for libcore prelude traits

- [#32976](https://github.com/rust-lang/rust/issues/32976) Tracking issue for adding more atomic integer types

## Deprecated + unstable (to remove)

- [#27700](https://github.com/rust-lang/rust/issues/27700) Tracking issue for allocation APIs

- [#27705](https://github.com/rust-lang/rust/issues/27705) Tracking issue for DNS in std::net

- [#34767](https://github.com/rust-lang/rust/issues/34767) Tracking issue for SipHash13/SipHash24

- [#39658](https://github.com/rust-lang/rust/issues/39658) \<ctype.h\> functions for AsciiExt

## Search false positives (found in tests)

- #0
- #1
- #2
- [#18199](https://github.com/rust-lang/rust/issues/18199) Warnings caused by examples in libstd should fail the doc tests
- [#27759](https://github.com/rust-lang/rust/issues/27759) rustdoc unstable should show feature name and issue
- [#32374](https://github.com/rust-lang/rust/issues/32374) Show unstable status for deprecated items
- [#38412](https://github.com/rust-lang/rust/issues/38412) internal compiler error: …/src/librustc/middle/stability.rs:516: encountered unmarked API
- #1234567890

---

<div class="post-metadata">

**Author:** ![djc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/djc/32/1592_2.png) [@djc](https://internals.rust-lang.org/u/djc)\
**Post date:** [March 18, 2018, 7:14am UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/2 "2018-03-18T07:14:15Z")

</div>

Awesome work, thank you for doing this!

---

<div class="post-metadata">

**Author:** ![gnzlbg](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gnzlbg/32/3858_2.png) [@gnzlbg](https://internals.rust-lang.org/u/gnzlbg)\
**Post date:** [March 18, 2018, 9:22am UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/3 "2018-03-18T09:22:10Z")

</div>

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_item`s 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.

---

<div class="post-metadata">

**Author:** ![SimonSapin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/simonsapin/32/3158_2.png) [@SimonSapin](https://internals.rust-lang.org/u/SimonSapin)\
**Post date:** [March 18, 2018, 10:30am UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/4 "2018-03-18T10:30:01Z")

</div>

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 🙂 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/](https://doc.rust-lang.org/nightly/std/), but I don’t mind doing more of that if it helps.

---

<div class="post-metadata">

**Author:** ![gnzlbg](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gnzlbg/32/3858_2.png) [@gnzlbg](https://internals.rust-lang.org/u/gnzlbg)\
**Post date:** [March 18, 2018, 10:48am UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/5 "2018-03-18T10:48:16Z")

</div>

> 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](https://doc.rust-lang.org/nightly/std/), 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.

---

<div class="post-metadata">

**Author:** ![leonardo](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/leonardo/32/1344_2.png) [@leonardo](https://internals.rust-lang.org/u/leonardo)\
**Post date:** [March 18, 2018, 12:36pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/6 "2018-03-18T12:36:50Z")

</div>

> [@SimonSapin](#):
>
> #27741 Tracking issue for step\_by stabilization

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.

---

<div class="post-metadata">

**Author:** ![SimonSapin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/simonsapin/32/3158_2.png) [@SimonSapin](https://internals.rust-lang.org/u/SimonSapin)\
**Post date:** [March 18, 2018, 12:56pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/7 "2018-03-18T12:56:14Z")

</div>

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](https://github.com/rust-lang/rust/issues/42168). FCP for the `Step` trait is _not_ proposed at this time.

---

<div class="post-metadata">

**Author:** ![FliegendeWurst](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/fliegendewurst/32/3029_2.png) [@FliegendeWurst](https://internals.rust-lang.org/u/FliegendeWurst)\
**Post date:** [March 23, 2018, 5:25pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/8 "2018-03-23T17:25:10Z")

</div>

What about non\_ascii\_idents? They are also unstable: [https://github.com/rust-lang/rust/issues/28979](https://github.com/rust-lang/rust/issues/28979)

---

<div class="post-metadata">

**Author:** ![SimonSapin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/simonsapin/32/3158_2.png) [@SimonSapin](https://internals.rust-lang.org/u/SimonSapin)\
**Post date:** [March 23, 2018, 6:16pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/9 "2018-03-23T18:16:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Gilnaa](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gilnaa/32/2942_2.png) [@Gilnaa](https://internals.rust-lang.org/u/Gilnaa)\
**Post date:** [March 25, 2018, 3:13pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/10 "2018-03-25T15:13:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![SimonSapin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/simonsapin/32/3158_2.png) [@SimonSapin](https://internals.rust-lang.org/u/SimonSapin)\
**Post date:** [March 25, 2018, 3:54pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/11 "2018-03-25T15:54:22Z")

</div>

Also not a standard library feature 🙂

---

<div class="post-metadata">

**Author:** ![Gilnaa](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gilnaa/32/2942_2.png) [@Gilnaa](https://internals.rust-lang.org/u/Gilnaa)\
**Post date:** [March 25, 2018, 4:09pm UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/12 "2018-03-25T16:09:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [March 25, 2019, 8:29am UTC](https://internals.rust-lang.org/t/survey-of-unstable-standard-library-features/7075/13 "2019-03-25T08:29:55Z")

</div>

Closed on March 25, 2019, 8:29am UTC

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