[swift-evolution] Proposal: Add Safe Subquence Access Via subscript For ColloctionType

[Dennis Lysenko]

Jordan, thanks for the clarification. It is pretty easy to check if your
index is in-bounds before subscripting. Just unexpected as most things
causing a runtime crash tend to be marked with a '!' (try!, unwrapping an
optional with !, implicitly unwrapped optionals...)

On Mon, Dec 14, 2015 at 6:52 PM Jordan Rose <jordan_rose at apple.com> wrote:

> These are good points to bring up, Dennis. I'm not one of the standard
> library authors, so I might not get this exactly right, but I'll try to
> address each point.
>
> On Dec 14, 2015, at 15:40, Dennis Lysenko <dennis.s.lysenko at gmail.com>
> wrote:
>
> Jordan, I think the inspiration here might come from Ruby. I must admit
> that seeing that `Array.first` returns an optional, but Array#subscript
> raises a runtime error when the index is out of bounds threw me for a loop.
> In Ruby, both Array#first and Array.subscript return an optional.
>
>
> I do remember there being a discussion about this. One of the arguments in
> favor of the current behavior was "seq.first ?? defaultValue", which isn't
> too uncommon. The equivalent with an arbitrary subscript comes up much less
> often.
>
> If one of the original tenets of swift was to provide greater compile-time
> null-safety, which it definitely seems it was given the commendable
> emphasis on optionals being easy to use, then returning an optional would
> be a solid way to go about subscripting. Think of it this way: when I call
> a method with nullable return value, I am forced to deal with the fact that
> the method can fail at compile time. When I subscript an array, I am not
> forced to deal with it at compile time, and it will fail at runtime instead.
>
>
> From my perspective, array subscripting is not "an operation that can
> fail". It just has a precondition on its input parameter. Optional return
> values force you to deal with *dynamic* failures, but array subscripting
> should never get to that point.
>
> I think the equivalent would be forcing the user to check the *input* rather
> than the *output,* just as you are forced to check whether an optional is
> nil *before* using it rather than *after.* If you ignore a method return
> value you're not actually dealing with its failure.
>
>
> Nullable subscripting is a big departure from the way most modern
> languages do things and that is why I don't blame you for rejecting it.
> That said, it is a pleasant change in the way you think about subscripting.
>
> As a closing thought, subscripting hashes returns an optional value. You
> might consider this a pretty big inconsistency with arrays. Let me flip
> your argument against optional array subscripting, for dictionaries: *When
> you are performing a subscript where the key is out of the key set, is it
> not a programmer error?*
>
>
> No, it is not; it is the canonical way to tell if a key has an entry in
> the dictionary, and the canonical way to insert a new entry into the
> dictionary. The same is not true for Array.
>
> (Note also that Dictionary's subscript that takes an Index does not return
> an optional result.)
>
> Jordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/d608429d/attachment.html>