> On Dec 19, 2015, at 8:27 PM, Dennis Lysenko <[email protected]> > wrote: > > Dave, perhaps we could use "^" as an anchor point for the start index and $ > as the anchor point for the end index? It's familiar to anyone who knows a > bit of regex, and all vim users. My main worry would be ^ is already infix > xor operator.
We could. Downsides: • it's a needless additional sigil • it requires a language extension to express x[^ + 3] unless we fake it with prefix operators ^- and ^+. > > On Fri, Dec 18, 2015 at 5:43 PM Paul Ossenbruggen via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > I would like to avoid what you currently have to do for iterating a > subcontainer. > > for a in container[0..container.count-4] { > // do something. > } > > The slicing syntax would certainly help in these common situations. Maybe > there are easy ways that I am not aware of. > > - Paul > >> On Dec 18, 2015, at 2:39 PM, Dave Abrahams via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Dec 18, 2015, at 1:46 PM, Joe Groff via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> >>>> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Examples: >>>> >>>> >>> l=[1,2,3,4,5] >>>> >>> l[-1] >>>> 5 >>>> >>> l[-2] >>>> 4 >>>> >>> l[2:4] >>>> [3, 4] >>>> >>> l[2:] >>>> [3, 4, 5] >>>> >>> l[-2:] >>>> [4, 5] >>>> >>> l[:3] >>>> [1, 2, 3] >>>> >>> l[::2] >>>> [1, 3, 5] >>>> >>> l[::] >>>> [1, 2, 3, 4, 5] >>> >>> Accepting negative indices is problematic for two reasons: it imposes >>> runtime overhead in the index operation to check the sign of the index; >>> also, it masks fencepost errors, since if you do foo[m-n] and n is >>> accidentally greater than m, you'll quietly load the wrong element instead >>> of trapping. I'd prefer something like D's `$-n` syntax for explicitly >>> annotating end-relative indexes. >> >> Yes, we already have facilities to do most of what Python can do here, but >> one major problem IMO is that the “language” of slicing is so non-uniform: >> we have [a..<b], dropFirst, dropLast, prefix, and suffix. Introducing “$” >> for this purpose could make it all hang together and also eliminate the “why >> does it have to be so hard to look at the 2nd character of a string?!” >> problem. That is, use the identifier “$” (yes, that’s an identifier in >> Swift) to denote the beginning-or-end of a collection. Thus, >> >> c[c.startIndex.advancedBy(3)] => c[$+3] // Python: c[3] >> c[c.endIndex.advancedBy(-3)] => c[$-3] // Python: c[-3] >> c.dropFirst(3) => c[$+3...] // Python: c[3:] >> c.dropLast(3) => c[..<$-3] // Python: c[:-3] >> c.prefix(3) => c[..<$+3] // Python: c[:3] >> c.suffix(3) => c[$-3...] // Python: c[-3:] >> >> It even has the nice connotation that, “this might be a little more >> expen$ive than plain indexing” (which it might, for non-random-access >> collections). I think the syntax is still a bit heavy, not least because of >> “..<“ and “...”, but the direction has potential. >> >> I haven’t had the time to really experiment with a design like this; the >> community might be able to help by prototyping and using some alternatives. >> You can do all of this outside the standard library with extensions. >> >> -Dave >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
