Skip to content

Commit 51b8684

Browse files
authored
Rollup merge of #90312 - r00ster91:search, r=Dylan-DPC
Fix some confusing wording and improve slice-search-related docs This adds more links between `contains` and `binary_search` because I do think they have some relevant connections. If your (big) slice happens to be sorted and you know it, surely you should be using `[3; 100].binary_search(&5).is_ok()` over `[3; 100].contains(&5)`? This also fixes the confusing "searches this sorted X" wording which just sounds really weird because it doesn't know whether it's actually sorted. It should be but it may not be. The new wording should make it clearer that you will probably want to sort it and in the same sentence it also mentions the related function `contains`. Similarly, this mentions `binary_search` on `contains`' docs. This also fixes some other minor stuff and inconsistencies.
2 parents 055bf4c + c186460 commit 51b8684

File tree

3 files changed

+35
-11
lines changed

3 files changed

+35
-11
lines changed

library/alloc/src/collections/linked_list.rs

+5-5
Original file line numberDiff line numberDiff line change
@@ -645,7 +645,7 @@ impl<T> LinkedList<T> {
645645
/// Returns `true` if the `LinkedList` contains an element equal to the
646646
/// given value.
647647
///
648-
/// This operation should compute in *O*(*n*) time.
648+
/// This operation should compute linearly in *O*(*n*) time.
649649
///
650650
/// # Examples
651651
///
@@ -1569,7 +1569,7 @@ impl<'a, T> CursorMut<'a, T> {
15691569
/// Appends an element to the front of the cursor's parent list. The node
15701570
/// that the cursor points to is unchanged, even if it is the "ghost" node.
15711571
///
1572-
/// This operation should compute in O(1) time.
1572+
/// This operation should compute in *O*(1) time.
15731573
// `push_front` continues to point to "ghost" when it addes a node to mimic
15741574
// the behavior of `insert_before` on an empty list.
15751575
#[unstable(feature = "linked_list_cursors", issue = "58533")]
@@ -1584,7 +1584,7 @@ impl<'a, T> CursorMut<'a, T> {
15841584
/// Appends an element to the back of the cursor's parent list. The node
15851585
/// that the cursor points to is unchanged, even if it is the "ghost" node.
15861586
///
1587-
/// This operation should compute in O(1) time.
1587+
/// This operation should compute in *O*(1) time.
15881588
#[unstable(feature = "linked_list_cursors", issue = "58533")]
15891589
pub fn push_back(&mut self, elt: T) {
15901590
// Safety: We know that `push_back` does not change the position in
@@ -1603,7 +1603,7 @@ impl<'a, T> CursorMut<'a, T> {
16031603
/// unchanged, unless it was pointing to the front element. In that case, it
16041604
/// points to the new front element.
16051605
///
1606-
/// This operation should compute in O(1) time.
1606+
/// This operation should compute in *O*(1) time.
16071607
#[unstable(feature = "linked_list_cursors", issue = "58533")]
16081608
pub fn pop_front(&mut self) -> Option<T> {
16091609
// We can't check if current is empty, we must check the list directly.
@@ -1630,7 +1630,7 @@ impl<'a, T> CursorMut<'a, T> {
16301630
/// unchanged, unless it was pointing to the back element. In that case, it
16311631
/// points to the "ghost" element.
16321632
///
1633-
/// This operation should compute in O(1) time.
1633+
/// This operation should compute in *O*(1) time.
16341634
#[unstable(feature = "linked_list_cursors", issue = "58533")]
16351635
pub fn pop_back(&mut self) -> Option<T> {
16361636
if self.list.is_empty() {

library/alloc/src/collections/vec_deque/mod.rs

+15-3
Original file line numberDiff line numberDiff line change
@@ -1342,6 +1342,12 @@ impl<T, A: Allocator> VecDeque<T, A> {
13421342
/// Returns `true` if the deque contains an element equal to the
13431343
/// given value.
13441344
///
1345+
/// This operation is *O*(*n*).
1346+
///
1347+
/// Note that if you have a sorted `VecDeque`, [`binary_search`] may be faster.
1348+
///
1349+
/// [`binary_search`]: VecDeque::binary_search
1350+
///
13451351
/// # Examples
13461352
///
13471353
/// ```
@@ -2560,7 +2566,8 @@ impl<T, A: Allocator> VecDeque<T, A> {
25602566
}
25612567
}
25622568

2563-
/// Binary searches the sorted deque for a given element.
2569+
/// Binary searches this `VecDeque` for a given element.
2570+
/// This behaves similarly to [`contains`] if this `VecDeque` is sorted.
25642571
///
25652572
/// If the value is found then [`Result::Ok`] is returned, containing the
25662573
/// index of the matching element. If there are multiple matches, then any
@@ -2570,6 +2577,7 @@ impl<T, A: Allocator> VecDeque<T, A> {
25702577
///
25712578
/// See also [`binary_search_by`], [`binary_search_by_key`], and [`partition_point`].
25722579
///
2580+
/// [`contains`]: VecDeque::contains
25732581
/// [`binary_search_by`]: VecDeque::binary_search_by
25742582
/// [`binary_search_by_key`]: VecDeque::binary_search_by_key
25752583
/// [`partition_point`]: VecDeque::partition_point
@@ -2614,7 +2622,8 @@ impl<T, A: Allocator> VecDeque<T, A> {
26142622
self.binary_search_by(|e| e.cmp(x))
26152623
}
26162624

2617-
/// Binary searches the sorted deque with a comparator function.
2625+
/// Binary searches this `VecDeque` with a comparator function.
2626+
/// This behaves similarly to [`contains`] if this `VecDeque` is sorted.
26182627
///
26192628
/// The comparator function should implement an order consistent
26202629
/// with the sort order of the deque, returning an order code that
@@ -2629,6 +2638,7 @@ impl<T, A: Allocator> VecDeque<T, A> {
26292638
///
26302639
/// See also [`binary_search`], [`binary_search_by_key`], and [`partition_point`].
26312640
///
2641+
/// [`contains`]: VecDeque::contains
26322642
/// [`binary_search`]: VecDeque::binary_search
26332643
/// [`binary_search_by_key`]: VecDeque::binary_search_by_key
26342644
/// [`partition_point`]: VecDeque::partition_point
@@ -2667,7 +2677,8 @@ impl<T, A: Allocator> VecDeque<T, A> {
26672677
}
26682678
}
26692679

2670-
/// Binary searches the sorted deque with a key extraction function.
2680+
/// Binary searches this `VecDeque` with a key extraction function.
2681+
/// This behaves similarly to [`contains`] if this `VecDeque` is sorted.
26712682
///
26722683
/// Assumes that the deque is sorted by the key, for instance with
26732684
/// [`make_contiguous().sort_by_key()`] using the same key extraction function.
@@ -2680,6 +2691,7 @@ impl<T, A: Allocator> VecDeque<T, A> {
26802691
///
26812692
/// See also [`binary_search`], [`binary_search_by`], and [`partition_point`].
26822693
///
2694+
/// [`contains`]: VecDeque::contains
26832695
/// [`make_contiguous().sort_by_key()`]: VecDeque::make_contiguous
26842696
/// [`binary_search`]: VecDeque::binary_search
26852697
/// [`binary_search_by`]: VecDeque::binary_search_by

library/core/src/slice/mod.rs

+15-3
Original file line numberDiff line numberDiff line change
@@ -2139,6 +2139,12 @@ impl<T> [T] {
21392139

21402140
/// Returns `true` if the slice contains an element with the given value.
21412141
///
2142+
/// This operation is *O*(*n*).
2143+
///
2144+
/// Note that if you have a sorted slice, [`binary_search`] may be faster.
2145+
///
2146+
/// [`binary_search`]: slice::binary_search
2147+
///
21422148
/// # Examples
21432149
///
21442150
/// ```
@@ -2298,7 +2304,8 @@ impl<T> [T] {
22982304
None
22992305
}
23002306

2301-
/// Binary searches this sorted slice for a given element.
2307+
/// Binary searches this slice for a given element.
2308+
/// This behaves similary to [`contains`] if this slice is sorted.
23022309
///
23032310
/// If the value is found then [`Result::Ok`] is returned, containing the
23042311
/// index of the matching element. If there are multiple matches, then any
@@ -2310,6 +2317,7 @@ impl<T> [T] {
23102317
///
23112318
/// See also [`binary_search_by`], [`binary_search_by_key`], and [`partition_point`].
23122319
///
2320+
/// [`contains`]: slice::contains
23132321
/// [`binary_search_by`]: slice::binary_search_by
23142322
/// [`binary_search_by_key`]: slice::binary_search_by_key
23152323
/// [`partition_point`]: slice::partition_point
@@ -2349,7 +2357,8 @@ impl<T> [T] {
23492357
self.binary_search_by(|p| p.cmp(x))
23502358
}
23512359

2352-
/// Binary searches this sorted slice with a comparator function.
2360+
/// Binary searches this slice with a comparator function.
2361+
/// This behaves similarly to [`contains`] if this slice is sorted.
23532362
///
23542363
/// The comparator function should implement an order consistent
23552364
/// with the sort order of the underlying slice, returning an
@@ -2366,6 +2375,7 @@ impl<T> [T] {
23662375
///
23672376
/// See also [`binary_search`], [`binary_search_by_key`], and [`partition_point`].
23682377
///
2378+
/// [`contains`]: slice::contains
23692379
/// [`binary_search`]: slice::binary_search
23702380
/// [`binary_search_by_key`]: slice::binary_search_by_key
23712381
/// [`partition_point`]: slice::partition_point
@@ -2424,7 +2434,8 @@ impl<T> [T] {
24242434
Err(left)
24252435
}
24262436

2427-
/// Binary searches this sorted slice with a key extraction function.
2437+
/// Binary searches this slice with a key extraction function.
2438+
/// This behaves similarly to [`contains`] if this slice is sorted.
24282439
///
24292440
/// Assumes that the slice is sorted by the key, for instance with
24302441
/// [`sort_by_key`] using the same key extraction function.
@@ -2439,6 +2450,7 @@ impl<T> [T] {
24392450
///
24402451
/// See also [`binary_search`], [`binary_search_by`], and [`partition_point`].
24412452
///
2453+
/// [`contains`]: slice::contains
24422454
/// [`sort_by_key`]: slice::sort_by_key
24432455
/// [`binary_search`]: slice::binary_search
24442456
/// [`binary_search_by`]: slice::binary_search_by

0 commit comments

Comments
 (0)