[swift-evolution] Compiler Optimization of Optional-returning Functions followed by '!'

[Karl Wagner]

> On 20 Jan 2017, at 07:41, Russ Bishop via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 19, 2017, at 4:17 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> For those times when you _don't_ know how many elements there are, don't care, and for some reason can't be bothered to get `array.count`, but you need to explicitly access an element by its index *and* have a useful fallback value, IMO it's reasonable to have an alternative subscript like the proposed `array[lenient: 10]`. But with facilities like `for...in`, `map`, etc., and others like `count` and `enumerated`, it's hard to argue that it's nearly as common a scenario as those where you are given a known-good index.
>> 
> 
> I’m not sure why people keep asking for this; the extension is trivial so anyone who wants it can have it:
> 
> extension Collection
> {
>     subscript(ifExists index: Index) -> Iterator.Element? {
>         guard index < self.endIndex else { return nil }
>         return self[index]
>     }
> }
> 
> // won't assert!
> myArray[ifExists: 42]
> 
> 
> 
> Russ
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Amen!

Although technically, you should do (startIndex..<endIndex).contains(index) — what about if somebody asked for something lower than startIndex? But yeah, it’s such a trivial extension.

Asking a Collection for an item at a specific index which does not exist is, let’s be clear, a nonsense operation.

let myArray = [] // empty array
// would all be valid
myArray[0]
myArray[-1]
myArray[Int64.max]

I think that’s ludicrous. It completely flies in the face of our current indexing/collection model, which is this: items are retrieved by an associated Index type, and the various types of collection define how you are able to actually get one of those indexes:

- Collection: Provides startIndex/endIndex anchors, can only get the Index after an existing Index
- BidirectionalCollection: Can also get the Index before an existing Index
- RandomAccessCollection: Can also get the Index at an arbitrary offset from an existing Index

So essentially what is being proposed is that you can subscript Collections by invalid Indexes (maybe an Index from another instance of that Collection, or one which in other ways violates the axioms of the indexing model). Not only that, but everything which uses an Index (e.g. suffix(from:)) would have to also return an Optional to account for a nonsense index being given.

Also, let’s not beat around the bush: this isn’t a general Collection feature, this is only for Array (because its Index is not an opaque type — if it was, invalid indexes would be even more obviously a result of your own bad logic).

So basically this is being driven by programmers who are **abusing** Array and its indexes. If Array.Index was an opaque type, none of this would be possible. For your convenience, the index was made an integer, but that doesn’t mean you can just pass in *any* integer. You still need to abide by the general Collection indexing model.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170121/29a9e5d0/attachment.html>