<div dir="ltr">+1 I think it is a good idea to make a collection run from firstIndex to lastIndex inclusively (note name change to match firstElement and lastElement). For an empty collection both firstIndex and lastIndex would be invalid values that would cause both c[c.firstIndex] and c.[c,lastIndex] to fail.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 24 March 2016 at 14:07, Andrew Bennett 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"><div dir="ltr"><div>Hi Pedro,</div><div><br></div><div>I'm going to refer to what you're proposing as <b>lastIndex</b> to distinguish it from the current endIndex.</div><div><br></div><div>Worth considering is indexes for things like a linked list (or other ForwardIndexType collections):<br></div><div><ul><li>You can represent the endIndex in O(1) by using a nullable internally.<br></li><li>It's likely to be an O(n) operation resolve the <b>lastIndex</b> property<b>.</b></li></ul><div><div>The current system seems much cleaner to represent empty ranges:</div><div><ul><li>How do you represent an empty range with <b>lastIndex</b>? Range(start: 0, end: -1) ?<br></li><li>Does this mean that UInt cannot be a ForwardIndexType, or cannot be used with Range, how do you show this in the protocol?</li></ul></div></div><div><div>You should also consider migration in your proposal:</div><div><ul><li>I don't think migration will be trivial, or even necessarily safely automated. I think the changes will be extensive.</li><li>Reusing the same name will likely make it confusing when people google Swift code, it will be unclear if code is in the old system or the new one.</li><li>If you do a formal proposal I recommend it proposes to deprecate the current system and introduce a new property with a different, clearer, name. I recommend <b>lastIndex</b>.</li></ul><div><br></div></div></div><div>It's probably worthwhile for you to consider your proposed changes in the context of this upcoming proposal, I think it's very likely to go ahead in some form:</div></div><div> <a href="https://github.com/gribozavr/swift-evolution/blob/new-collections/proposals/NNNN-collections-move-indices.md" target="_blank">https://github.com/gribozavr/swift-evolution/blob/new-collections/proposals/NNNN-collections-move-indices.md</a></div><div><br></div><div>I'm in favour of having a new field:</div><div><font face="monospace, monospace"> // for example</font></div><div><font face="monospace, monospace"> var lastIndex: Index? {</font></div><div><font face="monospace, monospace"> let count = self.count</font></div><div><font face="monospace, monospace"> guard count > 0 else { return nil }</font></div><div><font face="monospace, monospace"> return startIndex.advancedBy(count-1)</font></div><div><font face="monospace, monospace"> }</font></div><div><font face="monospace, monospace"><br></font></div>It's optional to represent an empty collection.<br><div><br></div><div>I'm not in favour of the proposal as it is stated. It's a fairly well established convention for endIndex to be the index after the last element, although perhaps it could be called something clearer. I think that discussion is a good idea.</div><div><br></div><div><br></div><div>Andrew Bennett</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 11:15 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
on Wed Mar 23 2016, Pedro Vieira <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Hi Swift developers,<br>
> I hereby present my first Swift proposal regarding the endIndex on<br>
> `Collections` and closed `Ranges`. I’ve searched the mailing list archives<br>
> for something similar to this but couldn’t find it, so I decided to come<br>
> forward.<br>
><br>
</span>> *The problem:*<br>
<span>> I was recently working on a library and used a closed Range to define the<br>
> bounds of a board game and the tests that used its endIndex were all<br>
> failing. Started debugging it around and, to my complete surprise, found<br>
> out that the endIndex of the closed Ranges was always +1 from the value I<br>
> initially set. With this, I decided to dive into the Range source code and<br>
> discovered that all closed ranges are converted to half-open ones when<br>
> initialized:<br>
> a) 1..<10 stays 1..<10 (endIndex = 10)<br>
> b) 1...10 is converted to 1..<11 (endIndex = 11)<br>
><br>
> To work around this behavior I had to subtract 1 every time I checked for<br>
> the endIndex, since I didn't want to use last! (force unwrapping) or<br>
> if-let, which ultimately polluted my code.<br>
<br>
</span>Please see the work currently underway in<br>
<a href="https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/ClosedRange.swift" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/ClosedRange.swift</a>,<br>
which we intend to propose soon. ClosedRange becomes a separate type<br>
that represents its upperBound without modification.<br>
<span><font color="#888888"><br>
<br>
--<br>
Dave<br>
</font></span><div><div><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>
</div></div></blockquote></div><br></div>
</div></div><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></blockquote></div><br></div>