On Thu, Jun 23, 2016 at 5:12 AM, Andreas Ley via swift-evolution < swift-evolution@swift.org> 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. > I can see where you're coming from, but IMO the ship has sailed to change the performance characteristics of every array currently written in Swift. Moreover, as Dave A. has pointed out before, crashing isn't "unsafe" in the sense it's used in Swift. It's actually quite safe, in that you're immediately prevented from doing anything nonsensical based on your incorrect assumption. If I saw a type called UnsafeArray, I'd imagine that it'd allow me to peek beyond the end of my array without crashing. > > - 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
