| But it's a 80% solution, just not the 80% the author likes. One of the main usage of `Range` is to be an iterator. The other is to causally slice data structures. For both use-cases would the proposed changes lead to major usability regressions and braking. Because you
can't compiler time enforce valid ranges as many are not
created at compiler time (e.g. `a.start()..b.mid()`) and
making range creation fallible would in practice be a
massive usability nightmare. E.g. consider `for x in (start..end).unwrap().iter { .. }` instead of `for x in start..end { .. }`. The current solution while imperfect was chosen to fit the most common use-cases of it best. For some very performance sensitive use cases where you need slicing of ranges and the way the std range does thinks is to slow/bad you can have alternatives which are faster but have usability drawbacks. But that's the exceptional case not the normal case. Many of the other examples shown also seem kinda strange.
E.g. `get_unchecked` as well defined as "an out of bounds array index" is well defined (it's only defined for Range<usize> it's also an unstable experimental API...). Range need clones => only in use-cases it was not primary designed for. Range is unsure when its valid => No it knows it's always valid but not all valid ranges can be used in all places without having errors, indexing a slice with a range can panic anyway (out of bounds access) so moving the error handling there is fairly sane. Also you really can't have fallible Range creation. Range hides a foot gune => any exclusive from-to range in any language has this problem, it's why in mathematics there are 4 types of ranges A Recipe for Rearranging Range => he/she somehow assumes you can magically make sure that start <= end without error handling but without that oversight on his/here part this changes would make Range a usability nightmare. |