Thanks to everyone who responded! Particularly Jose who provided links to
the Swift evolution discussion, one of which is still open, though deferred
from Swift 3. I'm adding some thoughts to individual contents below, but my
original question was answered.
Jeff, that makes sense after looking more closely at the source. I had
incorrectly assumed that the fatal error was happening in Swift code, but I
believe it is in the C++.
Brent, I've seen examples like that before, and I think I just might be
unable to see the forest for the trees. `map` seems like the clearly better
choice for the first two transformations. I haven't done any Cocoa
development, however, so I have no opinion to share there. In general,
though it does seem like `enumerated` should be adequate when people want
to have guaranteed values.
Zhou, allowing clients to handle bad accesses would certainly not cause
bugs. In the worst case, developers would litter ! around their array
accesses, and the same crashes that existed before will continue. The fact
that something similar happens in other languages is similarly
unconvincing. There are languages where this is not the case (Elm).
On Wed, Jul 20, 2016 at 10:07 PM H. Kofi Gumbs <firstname.lastname@example.org> wrote:
Hello Swift community,
Here's a philosophy I've struggled with since I started learning Swift.
In general, it seems that failable function calls return `Optional`s;
however, `Array`s violate this rule by failing fast at runtime. I
understand that subscripts can't throw, so the only way to fail fast is to
do so at runtime. I also realize that there are many implementations of the
`array[safe: index]` that I could choose to use instead. However, I do not
understand why the default behavior is still to fail at runtime. Especially
given how they are often introduced as a beginner-friendly data structure.
Am I missing some language philosophy or major decision?