[swift-evolution] Strings in Swift 4

[Matthew Johnson]

> On Jan 31, 2017, at 4:04 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> On Jan 31, 2017, at 11:32, Jaden Geller via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I think that is perfectly reasonable, but then it seems weird to be able to iterate over it (with no upper bound) independently of a collection). It would surprise me if
>> ```
>> for x in arr[arr.startIndex…] { print(x) }
>> ```
>> yielded different results than
>> ```
>> for i in arr.startIndex… { print(arr[i]) } // CRASH
>> ```
>> which it does under this model.
> 
> (I think this how it works... semantically, anyway) Since the upper bound isn't specified, it's inferred from the context.
> 
> In the first case, the context is as an index into an array, so the upper bound is inferred to be the last valid index.
> 
> In the second case, there is no context, so it goes to Int.max. Then, after the "wrong" context has been established, you try to index an array with numbers from the too-large range.
> 
> Semantically speaking, they're pretty different operations. Why is it surprising that they have different results?
> 
> I must say, I was originally rather fond of `0...` as a spelling, but IMO, Jaden and others have pointed out a real semantic issue.
> 
> A range is, to put it simply, the "stuff" between two end points. A "range with no upper bound" _has to be_ one that continues forever.
> The upper bound _must_ be infinity. What Dave Abrahams has described does not have the semantics of a range with no upper bound. He's describing a standalone lower bound with no "stuff." It stands to reason that such a type should not be a sequence at all. But we already use particular types for upper and lower bounds that aren't sequences, and they're plain numeric types. Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. It also yields the sensible result that `arr[from: i][upTo: j] == arr[upTo: j][from: i] == arr[i..<j]`.
> 
> If `0...` is to have the semantics of a range with no upper bound, I would expect `for i in 0...` to be an infinite loop, equivalent to `for i in stride(from: 0, through: Int.max, by: 1)` for Int.max+1 iterations and then trapping. Which is, well, silly. I'm coming around to thinking that `0...` is a sexy notation for something we don't need and a poor notation for something that's more cleanly expressed by plain numbers.


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).  

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.

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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20170131/5223c37f/attachment.html>