<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="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 class=""><br>
on Wed Mar 23 2016, Pedro Vieira <<a href="mailto:swift-evolution@swift.org">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 class="">> 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 class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Dave<br>
</font></span><div class="HOEnZb"><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>