Hi all,
With Chromium's switch to C++23, I would like to propose moving std::from_range and std::ranges::to from TBD to Allowed.
Proposed Usage:
std::from_range: Allows constructing containers directly from a range using the tagged constructor.
// Current C++20-style
std::vector<int> v(input_range.begin(), input_range.end());
// Proposed C++23-style
std::vector<int> v(std::from_range, input_range);
std::ranges::to (Direct Call): A powerful utility to convert any range to a container. It is particularly useful for containers like absl::flat_hash_set that do not yet implement the std::from_range constructor. std::ranges::to falls back to the iterator-pair constructor, saving us from manually unpacking iterators.
std::vector<int> vec = GetIds();
// Current: Manual iterator unpacking required
absl::flat_hash_set<int> s(vec.begin(), vec.end());
// Proposed: Clean and explicit conversion
auto s = std::ranges::to<absl::flat_hash_set<int>>(vec);
Clean ups:
We can remove base::from_range, which is a backport of the C++23 feature.
We can replace many usages of base::ToVector with the standard std::ranges::to<std::vector<...>>.
Restriction on Adaptor Syntax:
Consistent with the existing ban on range adaptors and pipe syntax in Chromium (due to build-time and readability concerns), I propose keeping the pipe-adaptor version of std::ranges::to banned.
Allowed: std::ranges::to<std::vector<int>>(input_range)
Banned: input_range | std::ranges::to<std::vector<int>>()
To enforce this, I plan to update PRESUBMIT.py to allow to in the std::ranges allowlist but add a specific check banning the no-argument version std::ranges::to<...>().
Thoughts?
--
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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CALB5Stb-jQgg7YW2cQF_1xRB7GiuYaJn7kdeTVgYT5oaFubH6w%40mail.gmail.com.
> Does std::vector<int> v = std::ranges::to(...) work? That's less verbose.
No, unfortunately that does not work. The result container type needs to be specified explicitly as a template parameter.
> std::ranges::to<std::vector<std::string_view>>(...) would be quite a mouthful. Shall we allow sticking to base::ToVector(...)? I think that the latter wins from a readability perspective.
You don't need to specify the element type, that is std::ranges::to<std::vector>(...) also works. That said, converting to std::vector is common enough of an operation, that it's worth making it as simple and concise as possible. The projection support in base::ToVector is also nice. All of the following would work:
auto vec = std::ranges::to<std::vector>(input_range);
std::vector vec(std::from_range, input_range);
auto vec = base::ToVector(input_range);