[Draft] Adding Safe indexing to Array

[Jens]

Note that the existing subscript traps on out of bounds, and it can do this because it is checking whether the index is out of bounds or not. So it is safe because it is checking that the index is within bounds and traps otherwise. If it really was unchecked and unsafe then it would allow us to read and write outside the allocated memory of the array (with undefined behavior as the result).

This meaning of the words "checked" and "unchecked" is already established in Swift (and probably other languages) through the existing compiler flag -Ounchecked, and for example:

/// Creates an instance with the given bounds.
///
/// Because this initializer does not perform any checks, it should be used
/// as an optimization only when you are absolutely certain that `lower` is
/// less than or equal to `upper`. Using the half-open range operator
/// (`..<`) to form `Range` instances is preferred.
///
/// - Parameter bounds: A tuple of the lower and upper bounds of the range.
public init(uncheckedBounds bounds: (lower: Range.Bound, upper: Range.Bound))

Which we can see in action here:

var a = 1
var b = -1
let r1 = a ..< b // Will trap (at runtime) because it is checked and safe!
let r2 = Range<Int>(uncheckedBounds: (a, b)) // OK, but dangerous/unsafe!

---

Here is a list of the previous mentions in this thread (some of them are only pointing out the confusion caused by trying to make checked/unchecked mean something else than it already does in Swift):

[Draft] Adding Safe indexing to Array

Some will reply that a[i] is already checked, and that a[checked: i] is redundant. "Lenient" is hard to read for non-native English speakers that have a limited vocabulary (and code readability is important). a[safe: i] matches what's is everyone's mind (avoid crash), but does not match "safe" as Swift likes to define it (comply to preconditions or crash). It could live with short and purely made-up subscripts, like a[at: i], or a[index: i]. We'd all get used to them, since it's quite a frequ…

[Draft] Adding Safe indexing to Array

Yeah, and it can also seem like you're saying that you've check i before passing it as an argument. lenient avoids these problems, as does anything that begins if*.

[Draft] Adding Safe indexing to Array

Quick question: Isn't the default version also checked in some way? Otherwise, how does it know to throw?

[Draft] Adding Safe indexing to Array

Yes, it's done in a function called _checkValidSubscript , which traps on invalid accesses.

[Draft] Adding Safe indexing to Array

I have already told that I don't like the idea, but if it ends up in the standard library, I agree that checked: is confusing as well. From @xwu's suggestions, I can live with some form of if*. How about a[checking: i]?

[Draft] Adding Safe indexing to Array

If you want the keyword to refer to the index, then surely unchecked: is what you want ("this index is unchecked, so be careful when looking in the array"). If you want the keyword to refer to the act of subscripting, then surely checking: is what you want ("…checking the index as you look in the array"). The problem with checked: is that it's supposed to mean "checked result with an unchecked index", which just seems confusing.

[Draft] Adding Safe indexing to Array

I don't like it either, and I agree that some form of a[ifXxx: i] would be less confusing than a[safe: i] and a[checked: i]. I think a[checking: i] is almost as confusing as a[checked: i] (since it sort of implies that a[i] wouldn't be checking the index). Perhaps a[existing: i] ... And IMHO the current proposal would actually add rather than remove an exception, as explained in my previous post. I think other options should be considered, like: Using a subscript for a new type (eg SpecialA…