The example would be:
```
  std::array<int, 5> a;
  a[std::cw<42>]; // compile-time error X

  std::bitset<5> b;
  b[std::cw<42>]; // compile-time error X

  int arr[] = {1, 2, 3, 4, 5, 6};
  std::mdspan m(arr, std::cw<2>, 3);
  m[std::cw<42>, 0]; // compile-time error X

  std::simd::vector<int> s;
  s[std::cw<42>]; // compile-time error X

  std::vector<int> v;
  v[std::cw<42>]; // no cw-overload, so run-time error X
```

I think this might be a bit far-fetched, because it changes the
long-standing expected use case of operator[]. More precisely, it provides
a more complex overload for operator[]. I don't know if it's worth it.

But for `mdspan`, this probably might be feasible because its
`operator[]` is already a variadic template, which means it can take
`std::cw<42>`, we just didn't perform a static inspection.



Hewill Kang <hewillk_at_[hidden]> 於 2025年11月16日 週日 上午2:52寫道：

> 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
>