I read this great post. But it shows an example where the problem is circumvented because the algorithm can work on a more general protocol. But the problem still persists for algorithms which make sense for any countable range (open and closed).
> On 13 Jan 2017, at 02:57, Adriano Ferreira <[email protected]> wrote: > > Hi Dave, > > I’m not arguing about correctness cause I understand the reasoning behind it, > but about the abstraction itself. > > I believe a simplified interface would be more fun to use and less confusing. > This post from Ole Begemann talks a little bit about this interesting idea. > > Best, > > —A > >>> On Jan 12, 2017, at 5:55 PM, David Sweeris <[email protected]> wrote: >>> >>> >>> On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution >>> <[email protected]> wrote: >>> >>> BTW, I agree with you, having the range type split is somewhat confusing, >>> specially for those new to the language. >> >> Do you mean that you think having two types is confusing, or that the way we >> currently split them is confusing? >> >> If it's the former, then I disagree... IIRC, open vs closed ranges is >> covered in high school math, and IMHO it's not too hard to see the >> usefulness of both "0..<5" and "1...5". >> >> If it's the latter, I think it's only confusing because, well, partly >> because we only implement half the kinds of ranges ("lower" is always >> closed, but that's another thread), but mostly because we don't have generic >> protocols yet. If we could write >> protocol Range<T> where T : WhateverTheCurrentConstraintsAre { >> var lower: T {get} >> var upper: T {get} >> } >> Then we could define the concrete types as >> struct CCRange<T>: Range<T> {...} >> struct CORange<T>: Range<T> {...} >> struct OCRange<T>: Range<T> {...} >> struct OORange<T>: Range<T> {...} >> (Or spell it out, "ClosedClosedRange", if you don't like the abbreviations.) >> Then in code, since `Range` doesn't have any "Self or associated type >> requirements", you can make just make it the type of a variable. In fact, if >> I'm not mistaken, the "..<" and "..." operators could even return a `Range` >> instead of the relevant concrete type >> var x = 0..<5 // "..<" returns `CORange as Range` >> x = 0...4 // "..." returns `CCRange as Range`, which is fine because x's >> type is `Range`, not `HalfOpenRange` (or whatever it's called now) >> We'd get full polymorphism between all the types of range without losing the >> value semantics we want, and the current method of overloading functions is >> still available if you need the speed of static dispatch. >> >> - Dave Sweeris >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
