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 <https://oleb.net/blog/2016/10/generic-range-algorithms/> from Ole Begemann talks a little bit about this interesting idea. Best, —A > On Jan 12, 2017, at 5:55 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution >> <swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
