[swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

[David Sweeris]

I still think the best solution is that proposal, plus allowing subscript setters to take a T if their getters return a T? or T!, to avoid the problem of `nil` becoming the wrong type in cases where T itself is NilLiteralConvertible.

- Dave Sweeris

> On Jun 23, 2016, at 7:34 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Please find the related proposal which was formed after the long discussion in the list:
> 
> https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md
> 
> Here is the pull request on the swift-evolution repo:
> https://github.com/apple/swift-evolution/pull/328
> 
> On 23.06.2016 13:12, Andreas Ley via swift-evolution wrote:
>> (First time using a mailing list; I hope this message ends up in the correct thread)
>> 
>> This is a topic that comes up regularly on the Swift evolution mailing list and off it.
>> After reading through all the respective threads again, there seem to be the following two camps:
>> 
>> Arguments made for crashing when accessing a non-existent index:
>> - fast
>> - shows bugs quickly
>> 
>> Arguments made in favor of returning an optional by default:
>> - safe (as in "doesn't crash")
>> - similar to what other modern languages do
>> - what an unexperienced Swift developer would expect
>> 
>> All are valid arguments, but for different use cases.
>> In my opinion, the biggest problem is that there's no indication that subscripting can crash on the default array. Alternative subscripts for bounded access wouldn't solve this either.
>> 
>> Maybe Swift should have two different array classes: A fast, fast-failing "UnsafeArray" and a default safe "Array". This would prevent unexpected crashes for new Swift programmers while still providing a faster alternative for those who do low-level stuff. The name "UnsafeArray" would clearly communicate that this class should be handled with care.
>> 
>> - Andreas
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution