+1. I recently learned that "Effects: Equivalent to:" implies the throwing behavior; if you change it to "Returns:" then you need to add a "Throws:" (even if "Throws: Nothing").

So that's why `operator[]` has "Effects: Equivalent to" instead of "Returns:" — so that it doesn't need a "Throws:". But `at` already "Throws:", so it might as well "Returns:".

Also, you have "Returns: `operator[](OtherIndexTypes... indices)` with bounds checking." What you should say is "Returns: (*this)[indices...]".

The best I've got for the "Throws" element is (still not good): "Throws: out_of_range if indices_i >= extent(i) for any indices_i in indices"

More arcane question: Can you explain why you're proposing `at` to have overloads taking both `span` and `const array&`?

I know it's for consistency with `span.at`; but then why does `span.at` have them?

I know it's for consistency with `span.operator[]`; but then why does `span.operator[]` have them?

My next hypothesis was that this was a relic of the world pre-P2447, where if you only had a `span<Extent>` overload you wouldn't be able to write `myspan[{1,2,3}]`. But now that that's fixed, we should be able to eliminate that overload. This is totally orthogonal to your paper, and I suppose the ball would be in my court to fix it since I authored P2447... :)

But when I try it out, I discover that `myspan[{1,2,3}]` never worked! `operator[]` is a template that takes `span<OtherExtent>`, and of course there's no way to deduce what that type should be.

I'm cc'ing Mark Hoemmen and Christian Trott — do you guys know what's the deal with mdspan's `at(const array&)` and `at(const span&)` overloads?  What would go wrong if both of them were removed? what if only `at(const array&)` were removed?

Thanks,

Arthur