Exactly, the idea is to return an empty array just like other languages do. (e.g. python)
- Luis On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution < [email protected]> wrote: > On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote: > >> One point which should be discussed is the following behaviour: >> >> let array = [0] >> // ranges are completely out of bounds and produce an error >> array[clamping: 1...2] // error >> array[clamping: -2...-1] // error >> >> Should a range which has no intersection with the indices of the >> collection >> produce an error or just clamp to 0..<0 respectively endIndex..<endIndex? >> > > I expect it will returns [] i.e. empty array, as no elements with > 1...2(-2..-1) indexes in the array. I understand `clamping` similar as > 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10] > will silently move the right position to allowed index(4), and > [0,1,2,3,4][clamping:-2...0] will move left position to 0, I expect that > in [0][clamping: 1...2] will try to move both limits to allowed, and as no > intersection - silently return empty array. > > >> Best regards >> Maximilian >> >> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution >> <[email protected] <mailto:[email protected]>>: >> >> It seems that there is a consensus that this proposal might be a good >>> addition to the standard library. All comments on this thread in the past >>> few weeks were related to naming, not around the behaviour or validity of >>> the proposed methods. So I will submit this proposal for review very soon >>> assuming that nobody else has strong arguments against it. :-) >>> >>> Proposal: >>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md >>> >>> If you have any corrections or suggestions to the proposal text itself, >>> please comment on this gist: >>> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8 >>> (or pull request to my repo) >>> >>> Regards, >>> >>> - Luis >>> >>> On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Please let me know if you have more suggestions or corrections on >>> this proposal. >>> I'm tempted to submit it for review. :-) >>> >>> - Luis >>> >>> On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> It sounds good, thanks for you suggestions @Vladimir, @Patrick >>> and @Brent. >>> >>> I've just updated the proposal: >>> >>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design >>> >>> - Luis >>> >>> On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> Yes, I feel like 'within' is much better than 'bounded'. >>> >>> How about such changes in proposal: >>> >>> a[bounded: -1 ..< 5] --> a[within: -1 ..< 5] (or a[inside: >>> -1 ..< 5] ) >>> >>> a[optional: 0 ..< 5] --> a[checking: 0 ..< 5] >>> a[optional: 5] --> a[checking: 5] >>> >>> ? >>> >>> On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote: >>> >>> 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 >>> <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> 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 >>> >>> 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 >>> >>> Regards, >>> >>> - Luis >>> >>> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. >>> Sousa >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] >>> >>> <mailto:[email protected]>>> 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 >>> >>> In short, doing that in Swift causes a runtime >>> error: >>> >>> leta =[1,2,3] >>> letb =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 >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto: >>> [email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
