<div dir="ltr">Many thanks, Vladimir, I wasn't familiar with this yet. :-)<div><br></div><div>- Luis</div><div class="gmail_extra">
<br><div class="gmail_quote">On Sun, Apr 24, 2016 at 7:10 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">We already have this feature(to append labels for substiption), so I believe it is possible to implement this proposal:<br>
<br>
class A {<br>
subscript(safe range: Range<Int>) -> [Int] {<br>
get { return [1,2,3] } set { print(newValue) }<br>
}<br>
<br>
subscript(truncate range: Range<Int>) -> [Int] {<br>
get { return [1,2,3] } set { print(newValue) }<br>
}<br>
}<br>
<br>
var a = A()<br>
<br>
var arr = a[safe: 0...10]<br>
print(arr)<br>
arr = a[truncate: 0...10]<br>
print(arr)<span class=""><br>
<br>
<br>
On 23.04.2016 12:25, Luis Henrique B. Sousa via swift-evolution wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
No, I got the half-joke on the python-like example. :-)<br>
<br>
I meant the label as part of the brackets content, right before the range<br>
itself. E.g. [truncate: Range<Index>]<br>
where "truncate" is the label I'm referring to.<br>
<br>
Thanks<br>
<br>
- Luis<br>
<br>
On Friday, April 22, 2016, Dave Abrahams via swift-evolution<br></span><div><div class="h5">
<<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>
<br>
on Fri Apr 22 2016, "Luis Henrique B. Sousa via swift-evolution"<br>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> is this syntax reasonably simple to implement?<br>
<br>
If you mean a syntax that allows 0..<-2, it's implementable but I'd be<br>
opposed to it. You'd have to introduce a new overload of ..< that<br>
produced something other than a Range or CountableRange, because those<br>
have a precondition that the LHS is <= the RHS.<br>
<br>
> Or is there another solution that would work with less impact in terms<br>
> of design? I mean the subscript with a label on it,<br>
> i.e. collection[label: Range<Index>]<br>
<br>
I'm sure there are lots of other possibilities :-)<br>
<br>
><br>
> It's been a while since the last feedback, so I'm doing some rewriting<br>
> on this proposal and still considering to submit it for review.<br>
><br>
> - Luis<br>
><br>
> On Wed, Apr 13, 2016 at 10:29 PM, Dave Abrahams via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> on Wed Apr 13 2016, Maximilian Hünenberger<br>
> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> > Should this new operator form a new range? How can this range<br>
know about<br>
> the<br>
> > array's indices?<br>
> ><br>
> > A while ago there was a proposal (unfortunately it was not<br>
discussed<br>
> enough)<br>
> > which introduced safe array indexing:<br>
> ><br>
> > array[safe: 3] // returns nil if index out of bounds<br>
><br>
> Wrong label, but I wouldn't be opposed to adding such an operator for<br>
> all Collections.<br>
><br>
> > So another way to handle this issue would be to make another<br>
subscript<br>
> like:<br>
> ><br>
> > array[truncate: -1...6]<br>
><br>
> That approach makes sense too. But then do we add<br>
><br>
> x[python: 0..<-2] // all but the last two elements?<br>
><br>
> ;^)<br>
><br>
> > Best regards<br>
> > - Maximilian<br>
> ><br>
> > Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via<br>
swift-evolution<br>
> > <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
> ><br>
> > The idea of having a new operator following the principles of<br>
overflow<br>
> > operators looks great. Two distinct operators doing implicit and<br>
> explicitly<br>
> > might really be a good way to go; it would be concise and<br>
wouldn't look<br>
> like<br>
> > some magic happened behind the scenes. I'd like to hear more<br>
opinions<br>
> about<br>
> > it.<br>
> ><br>
> > > what we'll have in case a[-1 &..< 5]? should this raise error<br>
or become<br>
> [0<br>
> > ..< 3] ? I think, the latter.<br>
> > I agree here, I'd choose the latter.<br>
> ><br>
> > From my perspective, the behaviour I'm proposing is what a<br>
considerable<br>
> > number of users expect, especially if coming from other<br>
languages that<br>
> > follow that path. Of course I'm not comparing languages here, but<br>
> > considering the Swift principles of being a safer language, in<br>
my opinion<br>
> > we'd rather have a partial slice than a crash in execution time<br>
(when the<br>
> > user is not totally aware of it).<br>
> ><br>
> > Many thanks for all your additions so far. It's really good to<br>
see that<br>
> > these things are not set in stone yet.<br>
> ><br>
> > - Luis<br>
> ><br>
> > On Apr 11, 2016 4:21 PM, "Vladimir.S via swift-evolution"<br>
> > <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> ><br>
> > +1 for the idea "in general". But I also think that explicit is<br>
better<br>
> than<br>
> > implicit, especially if we deal with possible errors. Just like<br>
we work<br>
> > in Swift with integer overflow : '+' will generate run time<br>
error, but<br>
> > saying &+ we point Swift that we know what we do.<br>
> ><br>
> > but.. what we'll have in case a[-1 &..< 5]? should this raise<br>
error or<br>
> > become [0 ..< 3] ? I think, the latter.<br>
> ><br>
> > On 11.04.2016 17:02, Haravikk via swift-evolution wrote:<br>
> ><br>
> > I like the idea in theory, but the question is; is it really<br>
safer to<br>
> > return a result that the developer may not have wanted, versus an<br>
> > error<br>
> > indicating that a mistake may have been made? I wonder if perhaps<br>
> > there<br>
> > could be an alternative, such as a variation of the operator like<br>
> > so:<br>
> ><br>
> > let b = a [0 &..< 5]// Equivalent to let b = a[0 ..< min(5,<br>
> > a.endIndex)],<br>
> > becomes let b = a[0 ..< 3]<br>
> ><br>
> > I’m just not sure that we can assume that an array index out of<br>
> > range error<br>
> > is okay without some kind of indication from the developer, as<br>
> > otherwise we<br>
> > could end up returning a partial slice, which could end up causing<br>
> > an error<br>
> > elsewhere where the size of the slice is assumed to be 5 but isn’t.<br>
> ><br>
> > On 11 Apr 2016, at 13:23, Luis Henrique B. Sousa via<br>
> > 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>
> > wrote:<br>
> ><br>
> > This proposal seeks to provide a safer ..< (aka half-open range<br>
> > operator)<br>
> > 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>
> ><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>
> ><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<br>
> > elements that<br>
> > are below the half-open operator, even though the number of<br>
> > elements is<br>
> > lesser than the ending of the half-open operator. So the example<br>
> > above<br>
> > would return [1,2,3].<br>
> > We can see this very behaviour in other languages, such as<br>
> > Python and<br>
> > Ruby as shown in the proposal draft.<br>
> ><br>
> > This would eliminate the need for verifications on the array<br>
> > size before<br>
> > slicing it -- and consequently runtime errors in cases when the<br>
> > programmer didn't.<br>
> ><br>
> > Viewing that it is my very first proposal, any feedback will be<br>
> > helpful.<br>
> ><br>
> > Thanks!<br>
> ><br>
> > Luis Henrique Borges<br>
> > @luishborges<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>
> > <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><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><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><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><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>
> Dave<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>
> _______________________________________________<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>
--<br>
Dave<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>
<br>
<br>
--<br>
<br>
<br>
---<br>
<br></div></div>
*Luís Henrique Borges*<br>
iOS Developer at IBM <<a href="http://ibm.com" rel="noreferrer" target="_blank">http://ibm.com</a>><br>
Dublin, Ireland - <a href="http://luish.github.com" rel="noreferrer" target="_blank">luish.github.com</a> <<a href="http://luish.github.com" rel="noreferrer" target="_blank">http://luish.github.com</a>><span class=""><br>
<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 class="HOEnZb"><div class="h5">
_______________________________________________<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>