]> git.lizzy.rs Git - rust.git/commit - src/tools/miri
Rollup merge of #95743 - yaahc:binary-search-clarification, r=Mark-Simulacrum
authorMatthias Krüger <matthias.krueger@famsik.de>
Mon, 11 Apr 2022 10:06:52 +0000 (12:06 +0200)
committerGitHub <noreply@github.com>
Mon, 11 Apr 2022 10:06:52 +0000 (12:06 +0200)
commite25bc303f1ba73b9ed1f83573bcb573f9c268c9f
tree5acdbc059fb5fda8c7e23519b48edcba5850895c
parent48a9e104dfafdec3a5d00d365229d6369939f433
parent0eb0d891ad2558f523527db8595c1daf03c5ca83
Rollup merge of #95743 - yaahc:binary-search-clarification, r=Mark-Simulacrum

Update binary_search example to instead redirect to partition_point

Inspired by discussion in the tracking issue for `Result::into_ok_or_err`: https://github.com/rust-lang/rust/issues/82223#issuecomment-1067098167

People are surprised by us not providing a `Result<T, T> -> T` conversion, and the main culprit for this confusion seems to be the `binary_search` API. We should instead redirect people to the equivalent API that implicitly does that `Result<T, T> -> T` conversion internally which should obviate the need for the `into_ok_or_err` function and give us time to work towards a more general solution that applies to all enums rather than just `Result` such as making or_patterns usable for situations like this via postfix `match`.

I choose to duplicate the example rather than simply moving it from `binary_search` to partition point because most of the confusion seems to arise when people are looking at `binary_search`. It makes sense to me to have the example presented immediately rather than requiring people to click through to even realize there is an example. If I had to put it in only one place I'd leave it in `binary_search` and remove it from `partition_point` but it seems pretty obviously relevant to `partition_point` so I figured the best option would be to duplicate it.
library/core/src/slice/mod.rs