<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. :-)<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>
<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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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>