[swift-evolution] Strings in Swift 4

[Matthew Johnson]

> On Feb 1, 2017, at 9:15 AM, Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com> wrote:
> 
> I am also +1.
> 
> 
> On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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

Thanks for reminding me of this.  I generally agree with Chris, but have no idea what the more complicated syntax for variadic generics might look like.  I guess what I’m looking for is some indication of what ideas (if any) there are about what this might look like.  A sketch of possible directions would be sufficient to answer the questions lurking in the back of my mind.

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

Yes, I agree.  They have been discussed in two different threads now and it really feels like incomplete (and infinite) ranges deserve discussion in their own right.  Would it make sense to draft a proposal based on the direction Jaden sketched as a point of focus for the thread (especially to help newcomers get up to speed)?

> 
> Nevin
> 
> 
> On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
> >
> >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/388d7a0b/attachment.html>