[swift-evolution] Strings in Swift 4

[Nevin Brackett-Rozinsky]

I am also +1.


On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> I’m still curious how postfix `…` would impact our options for variadic
> generics and tuple unpacking in the future.



Somebody who happens to have originally created Swift addressed this point
last week:


On Wed, Jan 25, 2017 at 8:49 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> In any case, it seems like an obviously good tradeoff to make the syntax
> for variadic generics more complicated if it makes one sided ranges more
> beautiful.
>
> -Chris
>


I think we should start a new thread for the discussion of incomplete
ranges though.

Nevin


On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> 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]`.
> >
> > There's a lot I dislike about `subscript(upTo/through/from:)`:
> >
> > 1. We have not previously been very satisfied with how understandable
> these labels are—for instance, we fiddled around with them a lot when we
> were looking at `stride(from:to/through:by:)` in Swift 3, and eventually
> settled on the originals because we couldn't find anything better. I don't
> think entrenching them further makes very much sense.
> >
> > 2. The fact that you *can* write `arr[from: i][upTo: j]`, and that this
> is equivalent to both `arr[upTo: j][from: i]` and `arr[i..<j]`, seems a bit
> weird. We aren't typically in the habit of providing redundant APIs like
> this.
> >
> > 3. Neither Stdlib nor the Apple frameworks currently contain *any*
> labeled subscripts, so this design would be unprecedented in the core
> language.
> >
> > 4. After a new programmer learns about subscripting with two-sided
> ranges, removing one of the bounds is a straightforward extension of what
> they already know. The argument label solution is more ad-hoc.
> >
> > 5. The argument label solution solves the immediate problem, but doesn't
> give us anything else.
> >
> > To understand what I mean by #5, consider the implementation. The plan
> is to introduce a `RangeExpression` protocol:
> >
> >       protocol RangeExpression {
> >               associatedtype Bound: Comparable
> >               func relative<C: Collection(to collection: C) where
> C.Index == Bound -> Range<Bound>
> >       }
> >
> > And then reduce the many manually-generated variants of `subscript(_:
> Range<Index>)` in `Collection` to just two:
> >
> >       protocol Collection {
> >               ...
> >               subscript(bounds: Range<Index>) -> SubSequence { get }
> >               ...
> >       }
> >
> >       extension Collection {
> >               ...
> >               subscript<Bounds: RangeExpression>(bounds: Bounds) where
> Bounds.Bound == Index -> SubSequence {
> >                       return self[bounds.relative(to: self)]
> >               }
> >               ...
> >       }
> >
> > This design would automatically, source-compatibly, handle several
> different existing types you can slice with:
> >
> > * ClosedRange
> > * CountableRange
> > * CountableClosedRange
> >
> > Plus the new types associated with incomplete ranges:
> >
> > * IncompleteRange
> > * IncompleteClosedRange
> >
> > Plus anything else we, or users, might want to add. For instance, I have
> a prototype built on `RangeExpression` which lets you write things like:
> >
> >       myString[.startIndex + 1 ..< .endIndex - 1]
> >
> > This strikes me as a pretty cool thing that some people might want.
> >
> > Similarly, IncompleteRange and IncompleteClosedRange can most likely be
> put to other uses. They could easily fill a gap in `switch` statements,
> which don't have a good way to express open-ended comparisons except with a
> `where` clause. As some have mentioned, when applied to a `Strideable` type
> they *could* be treated as infinite sequences, although it's not clear if
> we really want to do that. And, you know, sometimes you really *do* have a
> case where one or both bounds of a range may be missing in some cases;
> incomplete ranges are a built-in, batteries-included way to model that.
> >
> > To put it simply, slicing with incomplete ranges gives us several
> valuable tools we can apply to other problems. Labeled subscripts, on the
> other hand, are just another weird little thing that you have to memorize,
> and probably won’t.
>
> +1 in general.  But I’m still curious how postfix `…` would impact our
> options for variadic generics and tuple unpacking in the future.
>
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > _______________________________________________
> > 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/20170201/765310ee/attachment.html>