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

Matt Lewin matt at lewin.us
Wed Apr 19 09:47:19 CDT 2017


Haravikk-

Retaining the use of the binary operator using Void as the open end, certainly helps with readability. As I said in my initial comments, though, my gut is that these operators obfuscate the language. (i.e., it triggers the uninitiated to refer to the Swift documentation)

With that said, short of going with something akin to  s[first..<i] and  s[i..<last] , I don’t know how we can make it intuitive. Obviously, the first/last approach is pretty darn verbose, so it doesn’t do anything to address the initial concern about  s.startIndex  being tiresome to write.

As you point out, underscore does does have a nice consistency within the language. It also kind of looks like “open” to me.

Thanks.

-Matt

> On Apr 18, 2017, at 4:08 PM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 18 Apr 2017, at 15:29, Matt Lewin via swift-evolution <swift-evolution at swift.org <mailto: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/20170419/ff94d98c/attachment.html>


More information about the swift-evolution mailing list