| Age | Commit message (Collapse) | Author | Lines |
|
This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.
The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.
The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.
Close #12037
|
|
These are adequately covered by the Tuple2 trait.
|
|
Renames the `n*` and `n*_ref` tuple getters to `val*` and `ref*` respectively, and adds `mut*` getters.
|
|
|
|
|
|
|
|
|
|
appropriate use
Zero and One have precise definitions in mathematics. Documentation has been added to describe the appropriate uses for these traits and the laws that they should satisfy.
For more information regarding these identities, see the following wikipedia pages:
- http://wikipedia.org/wiki/Additive_identity
- http://wikipedia.org/wiki/Multiplicative_identity
|
|
Also documented a few issues
|
|
The old behaviour of `foo.n0()` is replaced by `foo.n0_ref().clone()`.
|
|
|
|
This removes the stacking of type parameters that occurs when invoking
trait methods, and fixes all places in the standard library that were
relying on it. It is somewhat awkward in places; I think we'll probably
want something like the `Foo::<for T>::new()` syntax.
|
|
replaced by iterators (generic composable `map` and `zip` adaptors)
|
|
Use Eq + Ord for lexicographical ordering of sequences.
For each of <, <=, >= or > as R, use::
[x, ..xs] R [y, ..ys] = if x != y { x R y } else { xs R ys }
Previous code using `a < b` and then `!(b < a)` for short-circuiting
fails on cases such as [1.0, 2.0] < [0.0/0.0, 3.0], where the first
element was effectively considered equal.
Containers like &[T] did also implement only one comparison operator `<`,
and derived the comparison results from this. This isn't correct either for
Ord.
Implement functions in `std::iterator::order::{lt,le,gt,ge,equal,cmp}` that all
iterable containers can use for lexical order.
We also visit tuple ordering, having the same problem and same solution
(but differing implementation).
|
|
cc #5898
|
|
|
|
Just like the Ord methods, Eq::ne needs to be implemented in terms of
the same operation on the elements.
|
|
Use the definition, where R is <, <=, >=, or >
[x, ..xs] R [y, ..ys] = if x != y { x R y } else { xs R ys }
Previously, tuples would only implement < and derive the other
comparisons from it; this is incorrect. Included are several testcases
involving NaN comparisons that are now correct.
Previously, tuples would consider an element equal if both a < b and
b < a were false, this was also incorrect.
|
|
(A,) did not have the trait implementations of 2- to 12- tuples.
|
|
|
|
|
|
|
|
is very common, and the replacement (.iter().transform().collect()) is very
ugly.
|
|
|
|
|
|
|
|
You can still initialize multiple variables at once with "let (x, y) = (1, 2)".
|
|
Adds documentation for various things that I understand.
Adds #[allow(missing_doc)] for lots of things that I don't understand.
|
|
This only changes the directory names; it does not change the "real"
metadata names.
|
|
|
|
|