On Mon, Apr 4, 2022 at 12:59 AM Marshall Clow via Boost <
boost@lists.boost.org> wrote:
Why not just check to see if the returned iterator == end () ?
Philosophical answer:
because find/find_if algorithm already knew that, he was just rude ;) and
did not give us back that information.
Practical answer:
I find writing !=.end spammy and potentially errorprone. I know it sounds
impossible to mess this up but in code that is not slideware mistakes can
happen. Also I prefer shorter code(when it comes to syntax spam, not
variable names) since for me it makes the logic more obvious.
Bonus :) answer:
Rust does it.
https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.find
Ben Deane used it in a talk:
https://www.youtube.com/watch?v=ojZbFIQSdl8&t=2138s
@Viktor I prefer to avoid pointers since they can be deleted and then bad
things can happen. But optional has similar functionality, it is just
harder to mistake for a something you need to delete... Also you can read
the Barry blog post on why he prefers optional over T*, here is picture
https://brevzin.github.io/assets/optional-vs-ptr.pnghe used to show they
are not really same....
@Andrey Semashev I almost never do anything
with the iterator except comparing it to the end(). Again it is not that I
use find_if every day, but I use it a lot and I honestly do not remember
that I ever wanted to do something further with the iterator. Actually last
time I did something with iterators returned from algorithm it was a return
value of upper_bound, not find/find_if.
So IDK what else to say, I was really thinking this API is much better,
especially if Marshall would be interested in allowing container
overloads(on compilers with concepts) so code would look like:
if (const auto maybe_val = ofind(v, x); maybe_val) {
fmt::print("{}\n", *maybe_val);
}
Beside fact that let or cauto would be much nicer than const auto I think
that code looks actually quite nice.
