[swift-evolution] Strings in Swift 4

Glenn Adams flgadams at gmail.com
Sun Jan 22 20:20:01 CST 2017


 +1 for # 1 also.

Glenn


On Sun, Jan 22, 2017 at 9:07 PM James Hillhouse via swift-evolution <
swift-evolution at swift.org> wrote:

> +1 for #1
>
>
>
> Jim
>
>
>
>
>
> > On Jan 22, 2017, at 5:40 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >
>
> >
>
> >>> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >>>
>
> >>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >>>
>
> >>> on Fri Jan 20 2017, Joe Groff <swift-evolution at swift.org> wrote:
>
> >>>
>
> >>>> Jordan points out that the generalized slicing syntax stomps on '...x'
>
> >>>> and 'x...', which would be somewhat obvious candidates for variadic
>
> >>>> splatting if that ever becomes a thing. Now, variadics are a much more
>
> >>>> esoteric feature and slicing is much more important to day-to-day
>
> >>>> programming, so this isn't the end of the world IMO, but it is
>
> >>>> something we'd be giving up.
>
> >>>
>
> >>> Good point, Jordan.
>
> >>
>
> >> In my experiments with introducing one-sided operators in Swift 3, I
> was not able to find a case where you actually wanted to write `c[i...]`.
> Everything I tried needed to use `c[i..<]` instead. My conclusion was that
> there was no possible use for postfix `...`; after all, `c[i...]` means
> `c[i...c.endIndex]`, which means `c[i..<c.index(after: c.endIndex)]`, which
> violates a precondition on `index(after:)`.
>
> >
>
> > Right, the only sensible semantics for a one sided range with an open
> end point is that it goes to the end of the collection.  I see a few
> different potential colors to paint this bikeshed with, all of which would
> have the semantics “c[i..<c.endIndex]”:
>
> >
>
> > 1) Provide "c[i...]":
>
> > 2) Provide "c[i..<]":
>
> > 3) Provide both "c[i..<]” and "c[i…]":
>
> >
>
> > Since all of these operations would have the same behavior, it comes
> down to subjective questions:
>
> >
>
> > a) Do we want redundancy?  IMO, no, which is why #3 is not very
> desirable.
>
> > b) Which is easier to explain to people?  As you say, "i..< is shorthand
> for i..<endindex” is nice and simple, which leans towards #2.
>
> > c) Which is subjectively nicer looking?  IMO, #1 is much nicer
> typographically.  The ..< formulation looks like symbol soup, particularly
> because most folks would not put a space before ].
>
> >
>
> > There is no obvious winner, but to me, I tend to prefer #1.  What do
> other folks think?
>
> >
>
> >> If that's the case, you can reserve postfix `...` for future variadics
> features, while using prefix `...` for these one-sided ranges.
>
> >
>
> > I’m personally not very worried about this, the feature doesn’t exist
> yet and there are lots of ways to spell it.  This is something that could
> and probably should deserve a more explicit/heavy syntax for clarity.
>
> >
>
> > -Chris
>
> > _______________________________________________
>
> > swift-evolution mailing list
>
> > swift-evolution at swift.org
>
> > 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/20170123/62723886/attachment.html>


More information about the swift-evolution mailing list