4 ms·
At least based on this comment from the maintainer of the C++ NanoRanges library [0], it seems contracts (at one point) may be the intended method to bounds che
by aw1621107 4y ago
At least based on this comment from the maintainer of the C++ NanoRanges library [0], it seems contracts (at one point) may be the intended method to bounds check:
> I actually proposed at() for std::span as part of P1024r0. It was soundly defeated in LEWG, 0|0|4|4|5.
> I wasn’t there for the meeting, but from what I understand the feeling was that contracts (which at that time seemed highly likely for ‘20) were a better way to go for bounds checking, and that we should not be throwing exceptions for programmer errors like out-of-bounds access.
No idea whether that is still the case though.
[0]: https://old.reddit.com/r/cpp/comments/djqdu2/why_is_stdspan_is_missing_at/f48hhb5/ https://old.reddit.com/r/cpp/comments/djqdu2/why_is_stdspan_...
- bluGill 4y agoI'm not sure what the current thought is, but I'm hopeful contracts makes it into C++, and over a the next years (and iterations of the language) we find ways to make C++ better by proving the whole program correct. This will need a lot of tool support, and changes in the way people write code. However mathematical proofs of the program are the only thing I have left to make my code more reliable: humans are not perfect and unit tests have limits (proofs have different limits).
- WanderPanda 4y agoI don't entirely get the concept between mathematical proofs of programs. Is the basic idea that it is straight forward for humands to write down a correct NP hard specification and then let some algorithm proof the correctness of a more efficient algorithm for the same problem?
- bluGill 4y agoIt isn't straight forward. It is claimed to be possible and useful by advocates.
- pjmlp 4y agoKeep hoping then, it looks like it won't make C++26 as well.
- gpderetta 4y agoThere is a deep divide between those that believe that contract violations should never result in exceptions and those that believe that they should. In practice we end up with the worst of both worlds were we get inconsistent semantics on specific APIs depending on who's present on the day the feature is voted in (hence at for vector but not in span), while large changes like contracts never reach consensus. This is more and more of an issue with the c++ standardization process.