Date: Sun, 16 Nov 2025 02:52:07 +0800
Hi all,
C++26 introduced `std::cw` to represent compile-time constants, a stronger
alternative to integral_constant, see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2781r9.html
And we know that the C++26 Standard library has hardened a large number of
`operator[]`s, see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r4.html.
I'm wondering if combining `cw` and `operator[]` is the right direction.
For example, we could provide `cw` overloads for `operator[]` of containers
that have size information at compile time, such as `array<T, N>`, `span<T,
N>`, `inplace_vector<T, N>`, and it directly rejects out-of-bounds access
via Mandates:
```
constexpr reference operator[](integral-constant-like auto idx) const;
*Mandates*: idx < size() is true.
*Effects*: Equivalent to: return operator[decltype(idx)::value];
```
This seems to allow us to check for out-of-bounds issues at compile time,
avoiding runtime Hardened preconditions.
Is this reasonable?
Hewill
C++26 introduced `std::cw` to represent compile-time constants, a stronger
alternative to integral_constant, see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2781r9.html
And we know that the C++26 Standard library has hardened a large number of
`operator[]`s, see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r4.html.
I'm wondering if combining `cw` and `operator[]` is the right direction.
For example, we could provide `cw` overloads for `operator[]` of containers
that have size information at compile time, such as `array<T, N>`, `span<T,
N>`, `inplace_vector<T, N>`, and it directly rejects out-of-bounds access
via Mandates:
```
constexpr reference operator[](integral-constant-like auto idx) const;
*Mandates*: idx < size() is true.
*Effects*: Equivalent to: return operator[decltype(idx)::value];
```
This seems to allow us to check for out-of-bounds issues at compile time,
avoiding runtime Hardened preconditions.
Is this reasonable?
Hewill
Received on 2025-11-15 18:52:20
