I very much agree with Jordan that
at has no semantic difference from an unlabeled subscript. I think it's important to convey the behavioral difference of the API in the spelling.
Constraining the term "safe" to memory safety is unnecessary imo -- it's easy to say "memory safe" in a context that needs clarification. In the context of any given operation in Swift, I think "safe" can naturally generalize to mean "this won't mess up my program due to a programming error". It's a good term for this API in that sense, and would likely be useful in other areas as well.
With that said, here's my attempt at brainstorming for other spellings (including some suggested by others) that try to keep in mind all of the concerns that I've seen come up in the thread:
- Don't use "checked", since the unlabeled subscript is also checked.
- Don't use "safe", since that means memory safe.
- Convey the difference in functionality from the unlabeled subscript, which is that it returns nil instead of trapping on an out-of-bounds index.
I've also broken the spellings into groups based on what the subscript label is actually referencing, which I think is an important distinction to keep in mind.
Label references the index parameter:
values[unvalidated: index] (referencing that the index is unvalidated by the programmer rather than the API itself)
Label references the operation itself:
values[untrapping: index] or
Label references the return value:
We could also use a method rather than a subscript (though I'd personally prefer to keep the subscript to maintain symmetry with the unlabeled subscript):
imo, these are all clunky or confusing in different ways.
I'm not aware of any official guidelines on subscript label naming, but the only one that I know of in the standard library (
dictionary[key, default: value]) takes the approach of referencing the parameter rather than the operation or return value, which is also what makes the most sense to me. Admittedly,
safe as a subscript can be thought of as referencing the operation, but I think it's equally valid to say that it references the safety of the index itself.