Yes. The suggested implementation does use min/max: https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design
- Luis On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger < m.huenenber...@me.com> wrote: > I brought these up because the current implementation produces an error in > these cases. You have to insert additional min/max operations. > > Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa <lshso...@gmail.com > >: > > 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 < > swift-evolution@swift.org> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >>> >>> 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 >>>> <lshso...@gmail.com <mailto:lshso...@gmail.com>> 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 >>>> <lshso...@gmail.com <mailto:lshso...@gmail.com>> 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 >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>> 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 >>>> <swift-evolution@swift.org >>>> <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org >>>> <mailto:swift-evolution@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 >>>> >>>> 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 >>>> <lshso...@gmail.com <mailto:lshso...@gmail.com> >>>> <mailto:lshso...@gmail.com >>>> >>>> <mailto:lshso...@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 >>>> >>>> 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 >>>> swift-evolution@swift.org >>>> <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org >>>> <mailto:swift-evolution@swift.org>> >>>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto: >>>> swift-evolution@swift.org> >>>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org >>>> > >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution