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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
