Deprecates the `shuffle_mut` name in favour of `shuffle` too.
In future there will be many different types of owned
vectors/vector-likes (e.g. DST's ~[], Vec, SmallVec, Rope, ...), and so
privileging just `Vec` with the "functional" `shuffle` method is silly.
std: fix Cell's Show instance.
Previously it was printing the address of the Unsafe contained in the
Cell (i.e. the address of the Cell itself). This is clearly useless, and
was presumably a mistake due to writing `*&` instead of `&*`.
However, this later expression is likely also incorrect, since it takes
a reference into a Cell while other user code is executing (i.e. the
Show instance for the contained type), hence the contents should just be
copied out.
* push_all* operations should reserve capacity before pushing data to avoid unnecessary reallocations
* reserve_exact should never shrink, as specified in documentation
The `Float` trait methods will be usable as functions via UFCS, and
we came to a consensus to remove duplicate functions like this a long
time ago.
It does still make sense to keep the duplicate functions when the trait
methods are static, unless the decision to leave out the in-scope trait
name resolution for static methods changes.
move errno -> IoError converter into std, bubble up OSRng errors
Also adds a general errno -> `~str` converter to `std::os`, and makes the failure messages for the things using `OSRng` (e.g. (transitively) the task-local RNG, meaning hashmap initialisation failures aren't such a black box).
Previously it was printing the address of the Unsafe contained in the
Cell (i.e. the address of the Cell itself). This is clearly useless, and
was presumably a mistake due to writing `*&` instead of `&*`.
However, this later expression is likely also incorrect, since it takes
a reference into a Cell while other user code is executing (i.e. the
Show instance for the contained type), hence the contents should just be
copied out.
This is an implementation detail of the `f32` and `f64` modules and it
should not be public. It renames many functions and leaves out any
provided by LLVM intrinsics, so it is not a sensible binding to the C
standard library's math library and will never be a stable target.
This also removes the abuse of link_name so that this can be switched to
using automatically generated definitions in the future. This also
removes the `scalbn` binding as it is equivalent to `ldexp` when
`FLT_RADIX` is 2, which must always be true for Rust.
The various ...Rng::new() methods can hit IO errors from the OSRng they use,
and it seems sensible to expose them at a higher level. Unfortunately, writing
e.g. `StdRng::new().unwrap()` gives a much poorer error message than if it
failed internally, but this is a problem with all `IoResult`s.
This is an implementation of a portion of [RFC #4](https://github.com/rust-lang/rfcs/blob/master/active/0004-private-fields.md). This PR makes named struct fields private by default (as opposed to inherited by default).
The only real meaty change is the first commit to `rustc`, all other commits are just fallout of that change.
Summary of changes made:
* Named fields are private by default *everywhere*
* The `priv` keyword is now default-deny on named fields (done in a "lint" pass in privacy)
Changes yet to be done (before the RFC is closed)
* Change tuple structs to have private fields by default
* Remove `priv` enum variants
* Make `priv` a reserved keyword
The `Float` trait methods will be usable as functions via UFCS, and
we came to a consensus to remove duplicate functions like this a long
time ago.
It does still make sense to keep the duplicate functions when the trait
methods are static, unless the decision to leave out the in-scope trait
name resolution for static methods changes.
This commit switches privacy's checking of fields to have *all* fields be
private by default. This does not yet change tuple structs, this only affects
structs with named fields. The fallout of this change will follow shortly.
RFC: 0004-private-fields
cc #8122Closes#11809
The implementation of `Encodable<E, S>` for `Json` doesn't need to assume `S` to be `IoError`, only the default encoders for `Json` are depend on it. So this can be parametrize to increase flexiblity. If not, types that implement `Encoder<E>` where `E` is not `IoError` can't be worked with `Json`.
Huon Wilson
bors
Stepan Koltsov
Daniel Micay
Steven Fackler
Gábor Lehel
klutzy
Alex Crichton
Eunchong Yu