<div dir="ltr">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. :-)<div class="gmail_extra"><br></div><div class="gmail_extra">Proposal: <a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">If you have any corrections or suggestions to the proposal text itself, please comment on this gist:</div><div class="gmail_extra"><a href="https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8">https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8</a></div><div class="gmail_extra">(or pull request to my repo)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small">- Luis</div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa <span dir="ltr"><<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Please let me know if you have more suggestions or corrections on this proposal. </div><div class="gmail_extra">I'm tempted to submit it for review. :-)<span class=""><font color="#888888"><br clear="all"><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:small"><br></div><div dir="ltr"></div>- Luis</div></div></div></div></div></div></div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa <span dir="ltr"><<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.<div><br><div>I've just updated the proposal: </div><div><a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design</a></div></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small">- Luis</div></div></div></div></div></div></div></div></div></div></div></font></span><div><div>
<br><div class="gmail_quote">On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Yes, I feel like 'within' is much better than 'bounded'.<br>
<br>
How about such changes in proposal:<span><br>
<br>
a[bounded: -1 ..< 5] --> a[within: -1 ..< 5] (or a[inside: -1 ..< 5] )<br>
<br>
a[optional: 0 ..< 5] --> a[checking: 0 ..< 5]<br>
a[optional: 5] --> a[checking: 5]<br>
<br>
?<br>
<br></span>
On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I like the idea of the of the bounded subscript, however the optional one I<br>
feel could be used for clumsy code.<br>
<br>
.first and .last have value, but once you start stepping several arbitrary<br>
indices in, then that code is likely fragile?<br>
<br>
<br>
I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names<br>
for ‘bounded’ that attempt to explain what is going on:<br>
<br>
let a = [1, 2, 3]<br>
<br>
a[within: 0 ..< 5] // [1, 2, 3]<br>
a[inside: 0 ..< 5] // [1, 2, 3]<br>
a[intersecting: 0 ..< 5] // [1, 2, 3]<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution<br>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
<br>
As we have discussed throughout this thread, the initial proposal was<br>
modified to include alternative subscript methods instead of modifying<br>
the default operator/subscript behaviour.<br>
The first draft is<br>
here: <a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md</a><br>
<br>
I've also put this as a gist so that you can leave comments with respect<br>
to the proposal document itself. Any suggestion or help is very welcome.<br>
<a href="https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8" rel="noreferrer" target="_blank">https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8</a><br>
<br>
Regards,<br>
<br>
- Luis<br>
<br>
On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa<br>
<<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a> <mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>>> wrote:<br>
<br>
This proposal seeks to provide a safer ..< (aka half-open range<br>
operator) in order to avoid **Array index out of range** errors in<br>
execution time.<br>
<br>
Here is my first draft for this proposal:<br>
<a href="https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md</a><br>
<br>
In short, doing that in Swift causes a runtime error:<br>
<br>
leta =[1,2,3]<br>
letb =a[0..<5]<br>
print(b)<br>
<br>
> Error running code:<br>
> fatal error: Array index out of range<br>
<br>
The proposed solution is to slice the array returning all elements<br>
that are below the half-open operator, even though the number of<br>
elements is lesser than the ending of the half-open operator. So the<br>
example above would return [1,2,3].<br>
We can see this very behaviour in other languages, such as Python and<br>
Ruby as shown in the proposal draft.<br>
<br>
This would eliminate the need for verifications on the array size<br>
before slicing it -- and consequently runtime errors in cases when<br>
the programmer didn't.<br>
<br>
Viewing that it is my very first proposal, any feedback will be helpful.<br>
<br>
Thanks!<br>
<br>
Luis Henrique Borges<br>
@luishborges<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><span>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</span></blockquote><div><div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>