I entirely agree with you on the desired behavior of `zip(...)`. 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.
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 `[]`. 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...`. On Tue, Jan 31, 2017 at 21:39 Dave Abrahams <[email protected]> wrote: > > on Tue Jan 31 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote: > > > But that's not getting to the biggest hitch with your proposal. If > > subscript were lenient, then `arr[lenient: 42...]` would also have to > give > > you a result even if `arr.count == 21`. > > > > This is not at all what Dave Abrahams was proposing, though (unless I > > totally misunderstand). He truly doesn't want an infinite range. He wants > > to use a terser notation for saying: I want x to be the lower bound of a > > range for which I don't yet know (or haven't bothered to find out) the > > finite upper bound. It would be plainly clear, if spelled as `arr[from: > > 42]`, that if `arr.count < 43` then this expression will trap, but if > > `arr.count >= 43` then this expression will give you the rest of the > > elements. > > I think you do misunderstand. Notionally, 0... is an infinite range. > The basic programming model for numbers in swift is (to a first > approximation), program as if there's no overflow, and we'll catch you > by trapping if your assumption is wrong. It doesn't make sense for the > semantics of 0... to depend on the deduced type of 0 or the > representable range of Int > > for example, > > for x in zip(n..., someArray) { > > } > > How many iterations should this give you? If it doesn't process all of > someArray, I want a trap. > > -- > -Dave >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
