This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
[breaking-change]
* channel() - #[unstable]. This will likely remain forever
* sync_channel(n: int) - #[unstable with comment]. Concerns have ben raised
about the usage of the term "synchronous channel" because that generally only
applies to the case where n == 0. If n > 0 then these channels are often
referred to as buffered channels.
* Sender::send(), SyncSender::send(), Receiver::recv() - #[experimental]. These
functions directly violate the general guideline of not providing a failing
and non-failing variant. These functions were explicitly selected for being
excused from this guideline, but recent discussions have cast doubt on that
decision. These functions are #[experimental] for now until a decision is made
as they are candidates for removal.
* Sender::send_opt(), SyncSender::send_opt(), Receiver::recv_opt() - #[unstable
with a comment]. If the above no-`_opt` functions are removed, these functions
will be renamed to the non-`_opt` variants.
* SyncSender::try_send(), Receiver::try_recv() - #[unstable with a comment].
These return types of these functions to not follow general conventions. They
are consistent with the rest of the api, but not with the rest of the
libraries. Until their return types are nailed down, these functions are
#[unstable].
* Receiver::iter() - #[unstable]. This will likely remain forever.
* std::com::select - #[experimental]. The functionality is likely to remain in
some form forever, but it is highly unlikely to remain in its current form. It
is unknown how much breakage this will cause if and when the api is
redesigned, so the entire module and its components are all experimental.
* DuplexStream - #[deprecated]. This type is not composable with other channels
in terms of selection or other expected locations. It can also not be used
with ChanWriter and ChanReader, for example. Due to it being only lightly
used, and easily replaced with two channels, this type is being deprecated and
slated for removal.
* Clone for {,Sync}Sender - #[unstable]. This will likely remain forever.
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
[breaking-change]
