I entirely agree with you on the desired behavior of `zip(...)`.<br><br>However, if you insist on 0... being notionally an infinite range, then you would have to insist on `for i in 0...` also trapping. Which is not a big deal, IMO, but will surely make the anti-trapping crowd upset.<br><br>The bigger issue is that either you must have a lenient/clamping subscript for `arr[0...]` or it too must trap, which is not desired. However, if `arr[0...]` is clamping, then `[1, 2, 3][100...]` would not trap and instead give you `[]`.<br><br>If 0... is regarded as an incomplete range, your example of `zip(...)` could still trap as desired. It would trap on the notional attempt to assign someArray.count to IncompleteRange<T>.inferredUpperBound if count exceeds T.max. With such semantics for 0..., [1, 2, 3][0...] would behave as expected without the need for leniency, but [1, 2, 3][100...] would trap as I assume you'd expect. However, it would make no sense to write `for i in 0...`.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 31, 2017 at 21:39 Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
on Tue Jan 31 2017, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" class="gmail_msg" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
> But that's not getting to the biggest hitch with your proposal. If<br class="gmail_msg">
> subscript were lenient, then `arr[lenient: 42...]` would also have to give<br class="gmail_msg">
> you a result even if `arr.count == 21`.<br class="gmail_msg">
><br class="gmail_msg">
> This is not at all what Dave Abrahams was proposing, though (unless I<br class="gmail_msg">
> totally misunderstand). He truly doesn't want an infinite range. He wants<br class="gmail_msg">
> to use a terser notation for saying: I want x to be the lower bound of a<br class="gmail_msg">
> range for which I don't yet know (or haven't bothered to find out) the<br class="gmail_msg">
> finite upper bound. It would be plainly clear, if spelled as `arr[from:<br class="gmail_msg">
> 42]`, that if `arr.count < 43` then this expression will trap, but if<br class="gmail_msg">
> `arr.count >= 43` then this expression will give you the rest of the<br class="gmail_msg">
> elements.<br class="gmail_msg">
<br class="gmail_msg">
I think you do misunderstand. Notionally, 0... is an infinite range.<br class="gmail_msg">
The basic programming model for numbers in swift is (to a first<br class="gmail_msg">
approximation), program as if there's no overflow, and we'll catch you<br class="gmail_msg">
by trapping if your assumption is wrong. It doesn't make sense for the<br class="gmail_msg">
semantics of 0... to depend on the deduced type of 0 or the<br class="gmail_msg">
representable range of Int<br class="gmail_msg">
<br class="gmail_msg">
for example,<br class="gmail_msg">
<br class="gmail_msg">
for x in zip(n..., someArray) {<br class="gmail_msg">
<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
How many iterations should this give you? If it doesn't process all of<br class="gmail_msg">
someArray, I want a trap.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
-Dave<br class="gmail_msg">
</blockquote></div>