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> 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>> 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>> 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> >>> 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