TLDR: I'm contra signed-sizes. The size type is size_t and it's unsigned for a reason: There exists no negative size. If you get an unsigned value there is no need to check for below zero, if you get a signed value you might. It is the same there is `not_null<T>` in GSL(?). The whole discussion just shows that there is a problem with operations mixing signed and unsigned types in C++ in general. What we probably wanted was something like `size_t = not_negative<int>`, but well... Am 28.02.20 um 16:08 schrieb degski via Boost:
Yes, maybe (did you measure ?), but it does away with the 'comparing signed to unsigned' and the UB on signed overflow, does allow for optimizations.'
Suppose you need to store some (or many of those indexes (of type std::size_t), the better cache-locality (and lower memory use), will affect your performance. You mean using a 16- or 32-bit type as the size? Well there might be use cases for >4GB of "strings", although that's conceived. But curious: What usecase requires you to store that many indices that
I can pass that back: Did you measure the benefit of those UB-based optimizations? this matters?
There are certainly more use-cases. std::span almost had a ssize() param, but in the end (I believe) holding on to the past seems more important. I think it's more about consistency. But yes, due to the rules for mixing signed/unsigned ops this would have helped. I have never in my life seen a vector of size 2^32, even an array of chars that size is huge. The STL-solution to use std::size_t is totally arbitrary Is it? size_t used to be 32 bits unsigned. That is the most reasonable choice. The next better would be 16bit but I'm sure we agree that this would be to small. And in absence of a not_negative<int> a size is unsigned as is the underlying value space. there is always std::int64_t Not necessarily. IIRC it is optional With std::size_t's we easily introduce UB (and a bad one for that matter, because the wrapping of un-signed's might get unnoticed (luckily there is a warning, but nothing stops you from ignoring it)). With ranges and range-based for loops the operations on a size become less frequent. And it is easier to teach: Requesting a size? You'll get an unsigned value because it can never be negative. It avoids ambiguity. Compare that to a function returning a pointer: Are you supposed to check that for NULL or can you assume it never is?