> On Jan 31, 2017, at 5:20 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > > I think it’s fair to say that we get to decide on the semantics of postfix > `…`. “a range with no upper bound” is very reasonable, but wouldn’t another > reasonable semantics be “all the rest”, meaning that there *is* an upper > bound (the greatest possible value). > > "All the rest" is by itself insufficient so far as semantics: all the rest > _of what_? Supposing that our supplied lower bound is an integer, it must be > all the rest of the integers. It cannot be all the rest of whatever, where > whatever might be a collection that you try to subset with `0...`. (Recall > that collections move indices, but indices know nothing about the > collections.) It would be exceeding fuzzy for postfix `...` to mean "all the > rest of whatever I want it to mean"--that, almost tautologically, has no > semantics at all. > > Under the latter semantics, a `for i in 0…` loop would terminate after > reaching Int.max. This is probably not what the user intended and would > still crash when used in David’s example, but it’s worth considering. > > OK, I'm borderline fine with `0... == 0...Int.max`. It at least provides some > semantics (i.e., we're saying `...` refers to all the rest of the values > representable by the type used for the lower bound) [**]. But Jaden's point > still stands, since it would only be consistent if `for i in arr[0...]` then > traps after `arr.count` just like `for i in arr[0...Int.max]` would do. > Otherwise, we really are fudging the semantics.
If we really want to be honest about the information a value produced using postfix `…` carries, it is a partial range with only the lower bound specified. This allows us to assign meaning to that partial range using additional context: * When it is possible to increment Bound directly could be interpreted as an (near?) infinite sequence that either terminates or traps when it reaches an unrepresentable value. * When Bound is an index and the partial range is used as a subscript argument it can be interpreted to mean “to the end of the collection”. This still leaves us with an out of bounds crash in David’s example that iterates over a partial range. This is an artifact of `Array` using Int as it’s `Index` rather than an opaque type that does not allow users to increment it directly rather than using a collection. Is the problem in David’s example really that different than the ability to directly index an array with any `Int` we want? It’s not the kind of thing that developers would do frequently. The first time they try it they will get a crash and will learn not to do it again. I’m not necessarily arguing one way or the other. I’m simply pointing out that “partial range” is a perfectly reasonable semantics to consider. > > [**] It is not perfectly consistent semantically because, as was discussed in > threads about our numeric protocols, our integer types are supposed to model > all integers, not just the ones that happen to be representable. Our model is > imperfect because not all integers fit into finite memory, but that's a > modeling artifact and not intentional semantics. IIUC, it would be otherwise > difficult to give a good accounting of, say, the semantics of addition if > arithmetic overflow were an intentional part of the semantics and not an > artifact. I haven’t followed all of the details of the numeric protocol discussions. With this in mind, I agree with your proposed semantics of trapping after `Int.max` as it sounds more consistent with this intent. > > I’m not sure if you read Ben’s post regarding `enumerated` or not, but he > gave the example of `zip(0…, sequence)` as a more general replacement for > `enumerated`. IMO, he makes a pretty strong case for this. > >> >> >> - Dave Sweeris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
