I have the impression we exchanged flexibility for correctness (the ability to
represent 0..<Int.max) and that it's wasn't worth the loss of flexibility.1
Or am I missing something?
> On 6 Sep 2016, at 08:15, David Hart via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hi people,
>
> I’ve recently started migrating some Swift 2 projects to Swift 3. I came
> across the split of Range into Range and ClosedRange and I’ve really
> struggled with it. Specifically, in Swift 2, I had a struct with a Range
> property that was initialised in many places with either a closed or open
> range:
>
> struct Day { … }
> struct Day : Comparable { … }
> struct Day : Strippable { … }
>
> struct Info {
> let name: String
> let range: Range<Day>
> }
>
> Info(name: "Christmas Vacation", range: twentyfith...thirtyfirst)
> Info(name: "Summer Vacation", range: someday..<otherday)
>
> Now, in Swift 3, it seems like we’ve lost a type to represent any range to
> allow an API client the flexibility to specify it as he wishes. Is there a
> solution to this problem through a protocol which both ranges conform to, or
> are we stuck with this because of the new API?
>
> protocol RangeType {
> associatedtype Bounds
> let lowerBound: Bound { get }
> let upperBound: Bound { get }
> // what else? not even sure if it is possible to define such a protocol
> }
>
> David.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
