- Do we really need yet another non orthogonal thingy.
- Readability
- data[10][10]
- at(at(data,10),10) // I felt a bunch of my neurones explode on that one. And I did not put in the namespaces. That would could mean including <range> ? I'm guessing <range> might be as costly as <string>.
This is on track (but not in yet) to be data[10, 10] for C++23; removal of comma in operator[] was received favorable and I believe the Committee is in favor of deprecating, removing, and fixing all in one cycle, thank god. We can do the same for at() and make it variadic: at(data, 10, 10). A little more template boilerplate to do but it's do-able, I guess.
This is off-topic from std::span::at, but FYI— My understanding (and very strong preference) is that multi-argument `operator[]` should NOT be used as a hacky tool to save one character ([i][j] versus [i,j]). That's not its purpose. The purpose is better language-level support for multidimensional objects, e.g. myQuadtree[x,y], not terse support for nested one-dimensional objects. If I have a std::vector<std::string> vs, I access the nth character of the mth string with vs[m][n], just like in C++98. If I have an array of arrays `as`, I access the jth element of the ith array with as[i][j], just like in C++98.
The library writer would implement a multidimensional operator[] — or a multidimensional at() — only for user-defined class types that are actually multidimensional. For example, instead of representing a matrix as a "one-dimensional array of one-dimensional rows," the author could now choose to represent it opaquely as a 2D data structure.
ArrayOfRows rows; rows[i][j] =
rows.at(i).at(j);
Matrix mat; mat[i,j] =
mat.at(i,j);
Conclusion: If I have a single-dimensional std::vector<T> v, I do not want std::at(v, i, j) to compile. Not even if T is std::string!
–Arthur