I would very much like to know what the status is of conditional conformances and if there’s a timeline for them or they are underway or whatnot. My unscientific gut check suggests something like 50% of recent proposals or rough ideas have been impaired by their absence. :P
l8r Sean > On Jan 12, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > I agree that there are use cases where the distinction between ClosedRange > and Range is less ergonomic than perhaps possible. However, I would be very > much against rolling back the improved correctness, but as has been suggested > by a previous comment on the swift-users lists, a protocol would not be out > of place. By current Swift conventions, and given our goal of as much source > compatibility as possible (i.e. not renaming `Range`), such a protocol would > be named `RangeProtocol`. > > At the moment, we actually have four range types: Range, CountableRange, > ClosedRange, CountableClosedRange. Once conditional conformances fall into > place, the Countable versions can go away. There are useful algorithms that > can ignore the distinction between an open range and a closed range when the > bounds are countable (e.g. Int) that do _not_ make sense when the bounds are > not countable (e.g. Float). This comes down to the fact that `0...(2 as Int)` > is in many ways another way of expressing `0..<(3 as Int)` but `0...(2 as > Float)` is very much not the same thing as `0..<(3 as Float)`. Therefore, IMO > it'd be wisest to hold off on designing a `RangeProtocol` until the requisite > generics features are implemented, so that the final design can take > advantage of such features for a maximally ergonomic but still correct design. > > > On Thu, Jan 12, 2017 at 3:44 PM, Adriano Ferreira via swift-evolution > <swift-evolution@swift.org> wrote: > Hi David, > > There were a few instances where this topic or similar came up at the Swift > Evolution List and Swift Users List. > > There’s even this interesting proposal that dwells with it while providing > more lenient subscripts to collections. > > BTW, I agree with you, having the range type split is somewhat confusing, > specially for those new to the language. > > Best, > > —A > >> On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello, >> >> Since the release of Swift 3, I’ve seen quite a few people (me included) >> experience a lot of friction with the new types for representing ranges. >> I’ve seen people confused when writing an API that takes a Range as argument >> but then can’t pass in a ClosedRange. Sometimes this can be fixed because >> the API should be written against a more general protocol, but sometimes >> that’s not the case. >> >> Those new types definitely seem to cause more problems than they fixed (the >> Int.max problem). Has the Standard Library team put any thought into this? >> >> Regards, >> 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 > > > _______________________________________________ > 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
