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
