Open stephanlachnit opened 12 months ago
@stephanlachnit Thanks for the suggestion! : - ) Are you considering writing that paper?
I think this is fine. There aren't really any additional concerns beyond the ones which would show up in span. So if span gets it mdspan also should. Was the proposal for span::at voted into C++26 in Kona? I didn't check.
Thanks for the suggestion! : - ) Are you considering writing that paper?
I have never written a C++ proposal and unfortunately would not be able to present in person at an ISO C++ standards meeting. I can try to write a paper draft, but I would probably need some help.
Edit: I started drafting a proposal at https://github.com/stephanlachnit/mdspan-at
I think this is fine. There aren't really any additional concerns beyond the ones which would show up in span. So if span gets it mdspan also should. Was the proposal for span::at voted into C++26 in Kona? I didn't check.
I'm not sure where to check, but according to https://github.com/cplusplus/papers/issues/1501#issuecomment-1806852050 yes.
@mhoemmen @crtrott I decided to give the paper a shot anyway, please take a look at my draft with wording relative to N4964 at https://stephanlachnit.github.io/mdspan-at/. Would you like to be co-authors and present it to the C++ standards committee?
I looked at the wording and I was wondering whether
Effects: Equivalent to:
operator[](OtherIndexTypes... indices)
with bounds checking
is sufficient and you don't need to repeat the constraints. Christian and Mark spent quite a bit of time in LWG so they would know.
@stephanlachnit wrote:
Would you like to be co-authors and present it to the C++ standards committee?
Thank you for taking interest in this. I should have expressed myself better: My personal view is that I'd rather not spend time adding .at
to mdspan
. I'm not speaking for Christian or any other people, just for myself. I wouldn't object if someone added it to mdspan
, but I personally don't want to spend time on it.
Given that OtherIndexTypes can be signed, shouldn't it also throw out_of_range if indices[i] < 0 for any indices[i] in indices? Or do you allow negative indexing?
My personal view is that I'd rather not spend time adding
.at
tomdspan
.
Note that a custom layout could do multidimensional bounds checking, and a custom accessor could do (1-D) bounds checking for any layout.
In C++26,
std::span
will get a::at
member function. It's probably a good idea to do this for mdspan as well. The function signatures would be the same as inoperator[]
:Another neat advantage is that this does not require the multidimensional subscript operator, meaning that the signature is identical between in pre C++23 code.
Related discussion on std-proposals: https://lists.isocpp.org/std-proposals/2023/11/index.php#msg8301