[swift-evolution] [swift-evolution-announce] [Review] SE-0172: One-sided Ranges

Haravikk swift-evolution at haravikk.me
Tue Apr 18 15:08:58 CDT 2017


> On 18 Apr 2017, at 15:29, Matt Lewin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In contrast, the proposed solution of 
> // half-open right-handed range
> let greeting = s[..<i]
> // closed right-handed range
> let withComma = s[...i]
> // left-handed range (no need for half-open variant)
> let location = s[i...]
> requires both the code-writer and the code-reader to infer the missing side is the start or end.
> 
> From my perspective, this obfuscates the language by reducing the ability of the code to be read as English. (One of the goals of Swift design, correct?)

I mentioned in an earlier reply that my preference would be to retain use of the binary operator and use Void as the open end like so:

func ... <T:Comparable>(lhs:T, rhs:Void) -> PartialRangeFrom<T> { … }
func ... <T:Comparable>(lhs:Void, rhs:T) -> PartialRangeTo<T> { … }

let rangeFrom = 5...()
let rangeTo = ()...5

Would that solve your concern? Ideally we could also push for underscore to become another alias for Void when used in such a context, so we could do:

let rangeFrom = 5..._
let rangeTo = _...5

This to me is a bit more explicit that one end of the range being left open on purpose. I initially considered some kind of other symbol, but I think Void/underscore is suitable enough, underscore especially as it's consistent with other features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/f45d0c95/attachment.html>


More information about the swift-evolution mailing list