Proposal: Allow a narrow subset of std::views to replace base:: equivalents

[Jan Wilken Dörrie]

Hi everyone,

I would like to propose moving a small, specific subset of std::views from Banned to Allowed.

Background Historically, std::views and range adaptors were banned due to concerns regarding compile-time overhead, optimization difficulties, and the subjective readability issues of chaining with operator|.

However, since we recently deployed a Clang plugin that actively bans the use of operator| for range adaptors, the pipe syntax won't compile anyway. By relying on direct function call syntax (e.g., std::views::reverse(range)), we naturally discourage deeply nested chaining, which mitigates the worst compile-time hits and readability concerns.

Motivation Currently, we are reimplementing quite a bit of the standard view machinery directly in base. Specifically, we maintain base::Zip, base::Reversed, and base::RangeAsRvalues. It would be significantly easier and reduce our maintenance burden to just use the std::views equivalents directly.

Proposal

1. Update c++-features.md to explicitly allow the following specific views:

• std::views::zip (to replace base::Zip)

• std::views::reverse (to replace base::Reversed)

• std::views::as_rvalue (to replace base::RangeAsRvalues)

2. Migrate existing usages of these base:: utilities to std::views:: and eventually deprecate the base:: versions.

If in the future folks find other utilities from <ranges> helpful, you are highly encouraged to propose them on the mailing list as separate proposals. For example, std::views::transform or std::views::enumerate also seem pretty useful.

Thoughts?

Best regards,

Jan

[Nico Weber]

Do you have numbers on compile time cost? I imagine some of the cost comes from including headers?

--
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/CALB5StZ21Nx_Qc6Hye-9WLUry1yKVXNjWAkjqnRo-2%3DvQs0%2BRw%40mail.gmail.com.

[Adam Rice]

I support this. I've had a bugfix for base::Zip in my backlog for a year.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADZ1XiaoU0W4Ofp%2B578RXxA1qp2uZvLt-LWcRPc%2B4Q1cKDVopQ%40mail.gmail.com.

[Jan Wilken Dörrie]

> Do you have numbers on compile time cost? I imagine some of the cost comes from including headers?

I put together a prototype CL (crrev.com/c/7991099) that replaces base::Zip, base::Reversed, and base::RangeAsRvalues with their std::views equivalents. I had to fix some tests since the concept requirements changed and would also have to submit https://crrev.com/i/9482516 to fix the Windows compile error.

Compile Size:
The compile-size trybot reported a small decrease in total compiler inputs size: -103.90 MiB (-0.04%). I expect this is due to only needing to #include <ranges> for std::views, which base::Reversed and base::RangeAsRvalues already transitively did anyway. For base::Zip this is not true, but we would no longer have to #include <algorithm> and <tuple>, which probably also helps.

Binary Size: The android-binary-size trybot showed a very minor increase of +6.7 KiB (6,816 bytes) (~ +0.004%). 

Compile Time:
I ran a 5-trial benchmark building base_unittests cleanly (gn clean out/Default) with remote caching completely disabled (RBE_remote_accept_cache=false RBE_local_accept_cache=false).

| Metric | Baseline Mean (± SD) | Prototype Mean (± SD) | Absolute Delta |

| :-------------- | :------------------- | :-------------------- | :------------- |

| **Real (Wall)** | 44.77s (± 0.86s) | 43.30s (± 0.48s) | -1.47s |

| **User (CPU)** | 163.51s (± 1.63s) | 165.32s (± 0.74s) | +1.81s |

| **Sys (CPU)** | 132.30s (± 1.84s) | 130.36s (± 0.68s) | -1.94s |

| **Total CPU** | 295.81s (± 3.42s) | 295.68s (± 1.35s) | -0.13s |

The results are very close, but there is a small statistical significant win in wall time.

Best,
Jan

[Jan Wilken Dörrie]

Are there any outstanding concerns here? IIUC, the biggest worry with regard to compile times was overload resolution on operator| when chaining view operations. Since we outright block this on the compiler level, this should not concern us. The analysis above shows that compile size actually decreases compared to hand rolled implementations.

Assuming no further concerns are raised, I will mail out the CL to implement the style guide change in the near future.

Best,

Jan