<div dir="ltr"><div class="gmail_extra">Yes. The suggested implementation does use min/max:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design</a><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 dir="ltr" style="font-size:small"><br></div><div dir="ltr"></div>- Luis</div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger <span dir="ltr"><<a href="mailto:m.huenenberger@me.com" target="_blank">m.huenenberger@me.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="auto"><div></div><div>I brought these up because the current implementation produces an error in these cases. You have to insert additional min/max operations.</div><div><div class="h5"><div><br>Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa <<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">Exactly, the idea is to return an empty array just like other languages do. (e.g. python)<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 Sun, May 15, 2016 at 10:13 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"><span>On 15.05.2016 0:09, Maximilian Hünenberger 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">
One point which should be discussed is the following behaviour:<br>
<br>
let array = [0]<br>
// ranges are completely out of bounds and produce an error<br>
array[clamping: 1...2] // error<br>
array[clamping: -2...-1] // error<br>
<br>
Should a range which has no intersection with the indices of the collection<br>
produce an error or just clamp to 0..<0 respectively endIndex..<endIndex?<br>
</blockquote>
<br></span>
I expect it will returns [] i.e. empty array, as no elements with 1...2(-2..-1) indexes in the array. I understand `clamping` similar as 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10] will silently move the right position to allowed index(4), and [0,1,2,3,4][clamping:-2...0] will move left position to 0, I expect that in [0][clamping: 1...2] will try to move both limits to allowed, and as no intersection - silently return empty array.<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"><span>
<br>
Best regards<br>
Maximilian<br>
<br>
Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution<br></span>
<<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>
<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"><span>
It seems that there is a consensus that this proposal might be a good<br>
addition to the standard library. All comments on this thread in the past<br>
few weeks were related to naming, not around the behaviour or validity of<br>
the proposed methods. So I will submit this proposal for review very soon<br>
assuming that nobody else has strong arguments against it. :-)<br>
<br>
Proposal: <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>
If you have any corrections or suggestions to the proposal text itself,<br>
please comment on this gist:<br>
<a href="https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8" rel="noreferrer" target="_blank">https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8</a><br>
(or pull request to my repo)<br>
<br>
Regards,<br>
<br>
- Luis<br>
<br>
On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa<br></span><span>
<<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>
Please let me know if you have more suggestions or corrections on<br>
this proposal.<br>
I'm tempted to submit it for review. :-)<br>
<br>
- Luis<br>
<br>
On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa<br></span><span>
<<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>
It sounds good, thanks for you suggestions @Vladimir, @Patrick<br>
and @Brent.<br>
<br>
I've just updated the proposal:<br>
<a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design</a><br>
<br>
- Luis<br>
<br>
On Tue, May 10, 2016 at 6:50 AM, Vladimir.S via swift-evolution<br></span><div><div>
<<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>
Yes, I feel like 'within' is much better than 'bounded'.<br>
<br>
How about such changes in proposal:<br>
<br>
a[bounded: -1 ..< 5] --> a[within: -1 ..< 5] (or a[inside:<br>
-1 ..< 5] )<br>
<br>
a[optional: 0 ..< 5] --> a[checking: 0 ..< 5]<br>
a[optional: 5] --> a[checking: 5]<br>
<br>
?<br>
<br>
On 10.05.2016 6:27, Patrick Smith via swift-evolution wrote:<br>
<br>
I like the idea of the of the bounded subscript, however<br>
the optional one I<br>
feel could be used for clumsy code.<br>
<br>
.first and .last have value, but once you start stepping<br>
several arbitrary<br>
indices in, then that code is likely fragile?<br>
<br>
<br>
I can think of ‘within’, ‘inside’ and ‘intersecting’ as<br>
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>
On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa<br>
via swift-evolution<br>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br></div></div>
<mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span><br>
<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<br>
initial proposal was<br>
modified to include alternative subscript methods<br>
instead of modifying<br>
the default operator/subscript behaviour.<br>
The first draft is<br>
here:<br>
<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<br>
comments with respect<br>
to the proposal document itself. Any suggestion or<br>
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>><br></span>
<mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a><div><div><br>
<mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>>>> wrote:<br>
<br>
This proposal seeks to provide a safer ..< (aka<br>
half-open range<br>
operator) in order to avoid **Array index out of<br>
range** errors in<br>
execution time.<br>
<br>
Here is my first draft for this proposal:<br>
<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<br>
returning all elements<br>
that are below the half-open operator, even<br>
though the number of<br>
elements is lesser than the ending of the<br>
half-open operator. So the<br>
example above would return [1,2,3].<br>
We can see this very behaviour in other<br>
languages, such as Python and<br>
Ruby as shown in the proposal draft.<br>
<br>
This would eliminate the need for verifications<br>
on the array size<br>
before slicing it -- and consequently runtime<br>
errors in cases when<br>
the programmer didn't.<br>
<br>
Viewing that it is my very first proposal, any<br>
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><br>
<mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br></div></div>
<mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><span><br>
<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>
<br>
<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>
<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>
<br>
<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>
</span></blockquote><span>
<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></blockquote></div></div></div></blockquote></div><br></div></div>