Allow absl/algorithm/container.h in DEPS

[Andrew Rayskiy]

Hi all,

From what I see in DEPS, only optional/variant/int128 includes from absl are allowed. What about expanding this with container.h? I find these container functions pretty useful and much cleaner than their regular std counterparts. 

-- Andrew

[Kyle Charbonneau]

It looks like absl/algorithm/container.h is mostly STL algorithms that take a container, absl::c_sort(c), rather than two iterators, std::sort(c.begin(), c.end()). That overlaps pretty substantially with std::ranges algorithms. std::ranges is C++20 but Chrome has implemented most of it in base/ranges/algorithm.h, so the equivalent to absl::c_sort(c) would be base::ranges::sort(c).

Ideally we wouldn't allow another new set of container algorithms.

Kyle

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/6349830f-0335-47dd-8384-db93155ea4b0n%40chromium.org.

[Andrew Rayskiy]

base::ranges lack container versions of numeric algorithms -- in particular c_iota, c_accumulate and c_partial_sum. 

[K. Moon]

I think the argument that we should standardize on what C++20 will provide in the future, rather than what Abseil provides now, is persuasive. Most of these implementations seem to be fairly thin wrappers anyway, so not having two ways to do the same thing seems better to me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/91e6d5ac-037d-430f-8024-569ffa4eae3bn%40chromium.org.