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

Dave Abrahams dabrahams at apple.com
Fri Dec 18 16:39:47 CST 2015


> 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 <mailto: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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/1c25ebd1/attachment.html>


More information about the swift-evolution mailing list