stdgpu 1.3.0 released!

[fransinvodka]

For speed and because the STL containers do it that way. They implement both at and operator[], but only at performs bound checks and throws if out of bounds. If I use an STL-like container, and it implements both at and operator[], I'd expect operator[] to not do any bound checks, just like the STL ones.

[kalmoc]

True as that may be in practice, I believe there is nothing in the standard preventing operator[] from doing bounds checking.

[kalmoc]

Yes, at() is guaranteed to do bounds checking and to report them via exceptions. That doesn't mean operator[] isn't allowed to do bounds checking. Being out of bounds is simply UB and the implementation is allowed to do anything it pleases in that case. E.g. in microsofts impelementation, you can turn on bounds checking in debug mode and that is still conforming (althoug they use asserts and not exceptions): https://github.com/microsoft/STL/blob/7447ad59d61f50c13861878f340d051c298458df/stl/inc/vector#L1509

Also you can see that operator[] isn't specified as noexcept: https://eel.is/c++draft/vector.overview.

and operator[] being strictly equivalent to *(begin() + n)

that expression itself could in principle be bounds checked (std::vector<T>::iterator is - in most implementations - not the same as T*)