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? Best regards Maximilian > Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution > <[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]> >> 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]> 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]> 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]>> 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]>> 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]> >>>>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
