[swift-evolution] Proposal: Python's indexing and slicing

Dennis Lysenko dennis.s.lysenko at gmail.com
Sat Dec 19 22:27:36 CST 2015


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.

On Fri, Dec 18, 2015 at 5:43 PM Paul Ossenbruggen via swift-evolution <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 18, 2015, at 1:46 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution <
> swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/ef08321f/attachment.html>


More information about the swift-evolution mailing list