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

[Pierre Monod-Broca]

It just occurs to me that you can't put none<T> in a [T], so on optional subscript would only be get and we would need the current subscript beside anyway.

I have no particular opinion on the main subject, I wonder what the order of magnitude would be that optimisation.

Pierre

> Le 20 janv. 2017 à 07:41, Russ Bishop via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> On Jan 19, 2017, at 4:17 PM, Xiaodi Wu via swift-evolution <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170120/7cd3bfbe/attachment.html>