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

[Paweł Wojtkowiak]

Maybe writing s[s.startIndex..<i] isn't the worst thing, but writing classA.structB.stringC[classA.structB.stringC.startIndex..<i] is not beautiful or easy to read at all, and sometimes it can get really complex. Of course, you can assign these to variables first and then use them, but still I see no problem with the syntax from the proposal, at least for me there's nothing unclear with implicit "start" and "end" indices of a collection, and - in my opinion - it reads easier. Maybe that's because I have some experience with python, but I never considered this something difficult to learn or use, and it felt absolutely natural for me after I learned about it for the first time. One could say this adds complexity to the language, but I think this is a very convenient syntax and I don't think things like these, which can be explained in one sentence, should be rejected if they give a reasonable profit in terms of language usage fluency and readability (different people have different opinions and tastes though).  We could also say that ranges are unneccessary syntax and many others, but I think this one pays off when we take convenience, fluency and (imo) readability into account.

+1 from me on this proposal.

Wysłane z iPhone'a

Dnia 18.04.2017 o godz. 16:29 Matt Lewin <matt at lewin.us> napisał(a):

> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
> 
> My reply:
> Long-time reader, first time commenter.
> 
> I agree the need exists to slice up collections as described in the proposal. I also agree that Swift 3’s solution to this is jarring.
> 
> Given the example in the proposal:
> let s = "Hello, World!"
> let i = s.index(where: ",")
> let greeting = s[s.startIndex..<i]
> I agree that “s.startIndex” is tiresome to write. I question, though, whether it is harmful to readability.
> 
> 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?)
> 
> As an old Perl and Python hacker, the one-sided slicing example from Python, to me, is the perfect example of how those languages obfuscate in the name of brevity. Don’t get me wrong, I never had an issue with any of that when coding in those languages. The beauty of Swift, though, is that it can generally be read by the unindoctrinated.
> 
> Unfortunately, I don’t have a palatable alternative syntax solution. Honestly, I would go with s[s.startIndex..<i] for readability purposes.
> 
> I suppose we could do something similar to oldValue and newValue in getters and setters. (e.g., s[start..<i], s[i..<end] or s[first..<i], s[i..<last]) While such a thing still requires the layman to pause to consider where those pseudo-constants came from, because they are explicit they are at least somewhat intuitive.
> 
> Thanks for your consideration.
> 
> -Matt
> 
>> On Apr 18, 2017, at 12:40 AM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0172 "One-sided Ranges" begins now and runs through April 23, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> _______________________________________________
>> swift-evolution-announce mailing list
>> swift-evolution-announce at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170419/62e027ba/attachment.html>