Stability for core::cmp, core::default, alloc::rc, std::task #15797
Conversation
Mark Eq, PartialEq, Ord, PartialOrd as unstable: they will change slightly after trait reform. Equiv as experimental: better solutions are desired. min/max stable.
|
This also adds |
All stable.
Weak pointers experimental. Most everything else stable.
Most stable. deschedule/failing experimental because of concerns about naming and desirability. Adds task::name() to replace deprecated task::with_name().
| @@ -355,7 +365,20 @@ pub fn with_task_name<U>(blk: |Option<&str>| -> U) -> U { | |||
| } | |||
| } | |||
|
|
|||
| /// Read the name of the current task. | |||
| #[stable] | |||
| pub fn name() -> Option<String> { | |||
There was a problem hiding this comment.
There's no goal to remove this allocation? (Particularly because the name is often/sometimes a &'static str?)
There was a problem hiding this comment.
Inspecting the name is often a debugging utility, not done in performance critical contexts, so I don't think there's really any benefit in avoiding an allocation.
The only part that may be performance sensitive (not measured) would be spawning a task with a specific name and whether to special-case the &'static str case, but the actual inspection of the name seems much rarer.
There was a problem hiding this comment.
Maybe a logging library would include the task name in logged messages and thus being as performant as possible might be nice? (But yes, seems rare enough to not matter hugely.)
|
(Sorry for questioning things that have already been discussed!) |
Summary: * alloc::rc module stable * Rc type stable * Functions relating to weak references experimental * core::cmp module stable * PartialEq/Eq/PartialOrd/Ord unstable because trait reform will make them change again * Equiv experimental because there may be better sol'ns * lexical_ordering deprecated because it can be done trivially with the Ord trait * min/max stable * std::task module stable * TaskBuilder::stdout/stderr experimental because we aren't certain we want to configure the environment this way * try_future experimental because Future is experimental * try unstable because the error type might change * deschedule/failing unstable The major thing I did differently than previously-discussed is that I made `try` experimental: there's been discussion that the error type `Box<Any + Send>` is not sufficient. Per https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-07-16.md.
Summary:
The major thing I did differently than previously-discussed is that I made
tryexperimental: there's been discussion that the error typeBox<Any + Send>is not sufficient.Per https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-07-16.md.