about summary refs log tree commit diff
path: root/src/libcore/ops.rs
AgeCommit message (Collapse)AuthorLines
2016-08-24Use `#[prelude_import]` in `libcore`.Jeffrey Seyfried-6/+1
2016-08-24Rollup merge of #35876 - matthew-piziak:sub-examples, r=GuillaumeGomezJonathan Turner-19/+43
more evocative examples for `Sub` and `SubAssign` These examples are exactly analogous to those in PRs #35709 and #35806. I'll probably remove the `fn main` wrappers for `Add` and `Sub` once this is merged in. Part of #29365. r? @steveklabnik
2016-08-23add more-evocative examples for `Shl` and `Shr`Matthew Piziak-18/+76
r? @steveklabnik add examples that lift `<<` and `>>` to a trivial struct replace `Scalar` structs with struct tuples add `fn main` wrappers to enable Rust Playground "Run" button
2016-08-23replace `Div` example with something more evocative of divisionMatthew Piziak-9/+52
Analogous to PR #35860. r? @GuillaumeGomez
2016-08-23improve documentation for `Fn*` traitsMatthew Piziak-0/+165
I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits: - the relationship between these traits and the closures that implement them - examples of non-closure implementations - the relationship between these traits and Rust's ownership semantics add module-level documentation for `Fn*` traits Describe how `Fn*` traits, closure types, and ownership semantics are linked, and provide examples of higher-level functions that take `Fn*`s. more examples for `Fn*` traits create correct (though not yet elegant) examples for `FnMut` and `FnOnce` add trait links to module-level documentation third time's a charm! argument -> capture for trait documentation This wording will need to be supported with better examples for capturing eventually. correct `FnOnce` example I also fixed some of the trait wording here to make the concept of capturing clearer; though that still needs more work. replace `x + x` with `x * 2` for `fn double`
2016-08-22Rollup merge of #35864 - matthew-piziak:index-example, r=GuillaumeGomezJonathan Turner-13/+29
replace `Index` example with something more evocative of indexing r? @steveklabnik
2016-08-22Rollup merge of #35861 - matthew-piziak:rem-example, r=GuillaumeGomezJonathan Turner-11/+19
replace `Rem` example with something more evocative r? @steveklabnik
2016-08-22Rollup merge of #35860 - matthew-piziak:mul-example, r=GuillaumeGomezJonathan Turner-10/+47
replace `Mul` example with something more evocative of multiplication I may have gone a bit overboard on this one. Numbers are fun.
2016-08-22Rollup merge of #35809 - matthew-piziak:bitwise-and-example, r=GuillaumeGomezJonathan Turner-12/+27
replace `BitAnd` example with something more evocative of bitwise AND
2016-08-22more evocative examples for `Sub` and `SubAssign`Matthew Piziak-19/+43
These examples are exactly analogous to those in PRs #35709 and #35806. I'll probably remove the `fn main` wrappers for `Add` and `Sub` once this is merged in. Part of #29365. r? @steveklabnik
2016-08-22replace `BitAnd` example with something more evocative of bitwise ANDMatthew Piziak-12/+27
reformat method chain according to ubsan Rustic Style Guide https://ubsan.github.io/style/
2016-08-22replace `Mul` example with something more evocative of multiplicationMatthew Piziak-10/+47
I may have gone a bit overboard on this one. Numbers are fun. tone down the error message
2016-08-21Auto merge of #35777 - nrc:carrier3, r=@nikomatsakisbors-0/+72
Carrier trait (third attempt) This adds a `Carrier` trait to operate with `?`. The only public implementation is for `Result`, so effectively the trait does not exist, however, it ensures future compatibility for the `?` operator. This is not intended to be used, nor is it intended to be a long-term solution. Although this exact PR has not been through Crater, I do not expect it to be a breaking change based on putting numerous similar PRs though Crater in the past. cc: * [? tracking issue](https://github.com/rust-lang/rust/issues/31436) * [previous PR](https://github.com/rust-lang/rust/pull/35056) * [RFC issue](https://github.com/rust-lang/rfcs/issues/1718) for discussion of long-term Carrier trait solutions. r? @nikomatsakis
2016-08-20replace `Index` example with something more evocative of indexingMatthew Piziak-13/+29
r? @steveklabnik
2016-08-20replace `Rem` example with something more evocativeMatthew Piziak-11/+19
r? @steveklabnik
2016-08-20show how iterating over `RangeTo` and `RangeToInclusive` failsMatthew Piziak-12/+43
Feedback on PR #35701 seems to be positive, so this does the same thing for `RangeTo` and `RangeToInclusive`.
2016-08-20Rollup merge of #35830 - matthew-piziak:not-example, r=steveklabnikJonathan Turner-11/+22
replace `Neg` example with something more evocative of negation
2016-08-20Rollup merge of #35827 - matthew-piziak:neg-example, r=steveklabnikJonathan Turner-11/+16
replace `Not` example with something more evocative
2016-08-20Rollup merge of #35806 - matthew-piziak:addassign-example, r=steveklabnikJonathan Turner-10/+21
replace `AddAssign` example with something more evocative of addition This is analogous to PR #35709 for the `Add` trait.
2016-08-20Rollup merge of #35800 - matthew-piziak:mul-div-examples, r=steveklabnikJonathan Turner-0/+62
demonstrate `RHS != Self` use cases for `Mul` and `Div` Vector-scalar multipication is a good usecase for this. Thanks #rust!
2016-08-20Rollup merge of #35710 - matthew-piziak:explicit-drop, r=steveklabnikJonathan Turner-0/+7
note that calling drop() explicitly is a compiler error Part of #29365
2016-08-20Rollup merge of #35709 - matthew-piziak:add-trait-example, r=GuillaumeGomezJonathan Turner-11/+23
replace `Add` example with something more evocative of addition Currently most of the operator traits use trivial implementation examples that only perform side effects. Honestly, that might not be too bad for the sake of documentation; but anyway, here's a proposal to move a slightly modified version of the module-level point-addition example into the `Add` documentation, since it's more evocative of addition semantics. Part of #29365
2016-08-20Rollup merge of #35701 - matthew-piziak:rangefull-example-error, r=steveklabnikJonathan Turner-7/+20
explicitly show how iterating over `..` fails I've also removed the `main()` wrapper, which I believe is extraneous. LMK if that's incorrect.
2016-08-19replace `Neg` example with something more evocative of negationMatthew Piziak-11/+22
2016-08-19replace `Not` example with something more evocativeMatthew Piziak-11/+16
2016-08-19Remove the Option and bool impls for carrier and add a dummy implNick Cameron-60/+7
The dummy impl should ensure the same type checking behaviour as having other (real) Carrier impls.
2016-08-18replace `AddAssign` example with something more evocative of additionMatthew Piziak-10/+21
This is analogous to PR #35709 for the `Add` trait.
2016-08-18note that calling drop() explicitly is a compiler errorMatthew Piziak-0/+7
Part of #29365 explain that std::mem::drop in prelude will invoke Drop change "prelude" -> "the prelude"; change links to reference-style move link references to links' section
2016-08-18split example into three sections with explanationMatthew Piziak-3/+14
2016-08-18demonstrate `RHS != Self` use cases for `Mul` and `Div`Matthew Piziak-0/+62
Vector-scalar multipication is a good usecase for this. Thanks #rust!
2016-08-18Use a Carrier trait with the `?` operatorNick Cameron-0/+125
Allows use with `Option` and custom `Result`-like types.
2016-08-17replace Add example with something more evocative of additionMatthew Piziak-11/+23
Currently most of the operator traits use trivial implementation examples that only perform side effects. Honestly, that might not be too bad for the sake of documentation; but anyway, here's a proposal to move a slightly modified version of the module-level point-addition example into the `Add` documentation, since it's more evocative of addition semantics. Part of #29365 wrap identifiers in backticks minor rephrasing fix module-level documentation to be more truthful This branch changes the example for `Add` to no longer be a "minimum implementation that prints something to the screen".
2016-08-16RangeFull for-loop iteration fails because of IntoIteratorMatthew Piziak-1/+1
Saying that "[for-loop iteration] fails because .. has no IntoIterator impl" is more direct than saying "...no Iterator impl" because for loops sugar into IntoIterator invocations. It just happens that the other Range* operators implement Iterator and rely on the fact that `IntoIterator` is implemented for `T: Iterator`.
2016-08-15explicitly show how iterating over `..` failsMatthew Piziak-8/+10
I've also removed the `main()` wrapper, which I believe is extraneous. LMK if that's incorrect.
2016-08-15expound on limitations of Rust's trait-based operator overloadingMatthew Piziak-3/+8
Part of #29330
2016-07-08Stabilize `FnOnce::Output` + Fix rebasepetrochenkov-1/+1
2016-07-03std: Stabilize APIs for the 1.11.0 releaseAlex Crichton-23/+1
Although the set of APIs being stabilized this release is relatively small, the trains keep going! Listed below are the APIs in the standard library which have either transitioned from unstable to stable or those from unstable to deprecated. Stable * `BTreeMap::{append, split_off}` * `BTreeSet::{append, split_off}` * `Cell::get_mut` * `RefCell::get_mut` * `BinaryHeap::append` * `{f32, f64}::{to_degrees, to_radians}` - libcore stabilizations mirroring past libstd stabilizations * `Iterator::sum` * `Iterator::product` Deprecated * `{f32, f64}::next_after` * `{f32, f64}::integer_decode` * `{f32, f64}::ldexp` * `{f32, f64}::frexp` * `num::One` * `num::Zero` Added APIs (all unstable) * `iter::Sum` * `iter::Product` * `iter::Step` - a few methods were added to accomodate deprecation of One/Zero Removed APIs * `From<Range<T>> for RangeInclusive<T>` - everything about `RangeInclusive` is unstable Closes #27739 Closes #27752 Closes #32526 Closes #33444 Closes #34152 cc #34529 (new tracking issue)
2016-06-19doc: std::ops md formatting fixDaan Sprenkels-0/+1
2016-06-09make RangeInclusive Hash and !CopyAlex Burka-1/+1
[breaking-change] due to the removal of Copy which shouldn't have been there in the first place, as per policy set forth in #27186.
2016-06-09derive Hash for rangesAlex Burka-5/+5
Fixes #34170.
2016-06-05core: mark relevant functions with #[rustc_inherit_overflow_checks].Eduard Burtescu-0/+11
2016-04-13Add a note about overflowing in the `RangeFrom` iteratorTobias Bucher-0/+5
2016-03-24Add core::ops::Range*::contains() as per rust-lang/rust#32311NODA, Kai-6/+208
Signed-off-by: NODA, Kai <nodakai@gmail.com>
2016-03-20Update snapshots to 2016-03-18 (235d774).Eduard Burtescu-4/+0
2016-03-07Auto merge of #32051 - steveklabnik:gh9447, r=blussbors-1/+1
Fixes #9447
2016-03-06Auto merge of #30884 - durka:inclusive-ranges, r=aturonbors-5/+92
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges. This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals. - For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from https://github.com/rust-lang/rfcs/pull/1192#issuecomment-137864421. It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion. - I also kind of like @glaebhoerl's [idea](https://github.com/rust-lang/rfcs/pull/1254#issuecomment-147815299), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate. - There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging. cc @Gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq) cc #27777 #30877 rust-lang/rust#1192 rust-lang/rfcs#1254 relevant to #28237 (tracking issue)
2016-03-04add more unstable annotationsAlex Burka-0/+15
2016-03-04End stdlib module summaries with a full stop.Steve Klabnik-1/+1
Fixes #9447
2016-02-29std: Stabilize APIs for the 1.8 releaseAlex Crichton-50/+30
This commit is the result of the FCPs ending for the 1.8 release cycle for both the libs and the lang suteams. The full list of changes are: Stabilized * `braced_empty_structs` * `augmented_assignments` * `str::encode_utf16` - renamed from `utf16_units` * `str::EncodeUtf16` - renamed from `Utf16Units` * `Ref::map` * `RefMut::map` * `ptr::drop_in_place` * `time::Instant` * `time::SystemTime` * `{Instant,SystemTime}::now` * `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier` * `{Instant,SystemTime}::elapsed` * Various `Add`/`Sub` impls for `Time` and `SystemTime` * `SystemTimeError` * `SystemTimeError::duration` * Various impls for `SystemTimeError` * `UNIX_EPOCH` * `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign` Deprecated * Scoped TLS (the `scoped_thread_local!` macro) * `Ref::filter_map` * `RefMut::filter_map` * `RwLockReadGuard::map` * `RwLockWriteGuard::map` * `Condvar::wait_timeout_with` Closes #27714 Closes #27715 Closes #27746 Closes #27748 Closes #27908 Closes #29866
2016-02-27note work still to be doneAlex Burka-5/+7
In particular, uses of inclusive ranges within the standard library are still waiting. Slices and collections can be sliced with `usize` and `Range*<usize>`, but not yet `Range*Inclusive<usize>`. Also, we need to figure out what to do about `RangeArgument`. Currently it has `start()` and `end()` methods which are pretty much identical to `Range::start` and `Range::end`. For the same reason as Range itself, these methods can't express a range such as `0...255u8` without overflow. The easiest choice, it seems to me, is either changing the meaning of `end()` to be inclusive, or adding a new method, say `last()`, that is inclusive and specifying that `end()` returns `None` in cases where it would overflow. Changing the semantics would be a breaking change, but `RangeArgument` is unstable so maybe we should do it anyway.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 23:59:52 +0000