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
