<div dir="ltr"><div>is this syntax reasonably simple to implement? Or is there another solution that would work with less impact in terms of design? </div><div>I mean the subscript with a label on it, i.e. <font face="monospace, monospace">collection[label: Range<Index>]</font><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small">It's been a while since the last feedback, so I'm doing some rewriting on this proposal and still considering to submit it for review.</div><div style="font-size:small"><br></div><div style="font-size:small">- Luis</div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 13, 2016 at 10:29 PM, Dave Abrahams 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-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
on Wed Apr 13 2016, Maximilian Hünenberger <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Should this new operator form a new range? How can this range know about the<br>
> array's indices?<br>
><br>
> A while ago there was a proposal (unfortunately it was not discussed enough)<br>
> which introduced safe array indexing:<br>
><br>
> array[safe: 3] // returns nil if index out of bounds<br>
<br>
</span>Wrong label, but I wouldn't be opposed to adding such an operator for<br>
all Collections.<br>
<span class=""><br>
> So another way to handle this issue would be to make another subscript like:<br>
><br>
> array[truncate: -1...6]<br>
<br>
</span>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>
<div class=""><div class="h5"><br>
> Best regards<br>
> - Maximilian<br>
><br>
> Am 12.04.2016 um 01:21 schrieb Luis Henrique B. Sousa via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
> The idea of having a new operator following the principles of overflow<br>
> operators looks great. Two distinct operators doing implicit and explicitly<br>
> might really be a good way to go; it would be concise and wouldn't look like<br>
> some magic happened behind the scenes. I'd like to hear more opinions about<br>
> it.<br>
><br>
> > what we'll have in case a[-1 &..< 5]? should this raise error or become [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 considerable<br>
> number of users expect, especially if coming from other 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 my opinion<br>
> we'd rather have a partial slice than a crash in execution time (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 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">swift-evolution@swift.org</a>> wrote:<br>
><br>
> +1 for the idea "in general". But I also think that explicit is better than<br>
> implicit, especially if we deal with possible errors. Just like we work<br>
> in Swift with integer overflow : '+' will generate run time 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 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 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">swift-evolution@swift.org</a><br>
> <mailto:<a href="mailto:swift-evolution@swift.org">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>
> <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<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">swift-evolution@swift.org</a><br>
> <mailto:<a href="mailto:swift-evolution@swift.org">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">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">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">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">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>
</div></div><span class=""><font color="#888888">--<br>
Dave<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>