[swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

Patrick Smith pgwsmith at gmail.com
Mon May 9 22:27:52 CDT 2016

I like the idea of the of the bounded subscript, however the optional one I feel could be used for clumsy code.

.first and .last have value, but once you start stepping several arbitrary indices in, then that code is likely fragile?

I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names for ‘bounded’ that attempt to explain what is going on:

let a = [1, 2, 3]

a[within: 0 ..< 5] // [1, 2, 3]
a[inside: 0 ..< 5] // [1, 2, 3]
a[intersecting: 0 ..< 5] // [1, 2, 3]

> On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution <swift-evolution at swift.org> wrote:
> As we have discussed throughout this thread, the initial proposal was modified to include alternative subscript methods instead of modifying the default operator/subscript behaviour. 
> The first draft is here: https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md <https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md>
> I've also put this as a gist so that you can leave comments with respect to the proposal document itself. Any suggestion or help is very welcome.
> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8 <https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8>
> Regards,
> - Luis
> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa <lshsousa at gmail.com <mailto:lshsousa at gmail.com>> wrote:
> This proposal seeks to provide a safer ..< (aka half-open range operator) in order to avoid **Array index out of range** errors in execution time.
> Here is my first draft for this proposal: https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md <https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md>
> In short, doing that in Swift causes a runtime error:
> let a = [1,2,3]
> let b = a[0..<5]
> print(b)
> > Error running code: 
> > fatal error: Array index out of range
> The proposed solution is to slice the array returning all elements that are below the half-open operator, even though the number of elements is lesser than the ending of the half-open operator. So the example above would return [1,2,3]. 
> We can see this very behaviour in other languages, such as Python and Ruby as shown in the proposal draft.
> This would eliminate the need for verifications on the array size before slicing it -- and consequently runtime errors in cases when the programmer didn't. 
> Viewing that it is my very first proposal, any feedback will be helpful.
> Thanks!
> Luis Henrique Borges
> @luishborges
> _______________________________________________
> 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/20160510/307399c5/attachment.html>

More information about the swift-evolution mailing list