> Exactly equivalent to an already popular practice of passing array and its length next to each other.
Differences:
1. passing pointer and length next to each other is a convention. This means the compiler doesn't know about it.
2. you cannot turn array bounds checking on and off with a compiler switch (though we strongly recommend leaving it always on)
3. your array bounds checking convention won't be compatible with someone else's code (standardization is a big deal)
4. I've never seen it used for strings. Strings are a major beneficiary of bounds checking
5. You have to document this every time you use it.
6. it's clutter
7. there's no check that the array/length variables are not mixed up or otherwise confused with other variables
Most importantly, making a feature trivial to use makes for at least an order of magnitude increase in adoption of it. And what we want is adoption of it, right?
The proof is that array buffer overflows remain the #1 problem with C bugs.
P.S. I am always amazed at how C++ managed to get users to prefer:
std::vector<int> a;
int[] a;We can argue that C++ shouldn't have been that close to C, but that ship has sailed a long time ago.
In practice, C doesn’t have great idioms for error handling, and so a proposal here would also probably need to explain how the slice type would either reuse existing idioms or introduce a new idiom (like Rust’s use of sum types). That makes the scope much larger, which in turn might explain any hesitancy from the C WGs to accept something like this (although I’m not actually aware of any).
Now that you mention it, some method of forcing bounds checks in more limited circumstances might be nice for performance, that or a cleaner method of expressly disabling such for areas with critical performance and where the input is considered trusted or already validated.
I.e. they are not recoverable, so no need for error handling.
Many people have debated this and wanted such errors to be recoverable, but the principle in play is that the program is in an undefined state if there are such errors, and should not be allowed to continue as we wouldn't want it to launch nuclear missiles.
C’s lack of iterators also means that indexing bugs are more likely in idiomatic C programs than they are in equivalent C++ or D programs. This is another place where the standards body should improve things, but it also means that they’re somewhat constrained when it comes to slice proposals: making every index be potentially fatal is less palatable when your programming language doesn’t divert people away from indexing as much as it could.
In general my preferred way to handle OOB is an unchecked exception (like in Rust or C#), but that's not really an option C.