RangeExpression is a protocol for all ranges, including partial and unbounded ranges. It would not make sense for such a protocol to have an upper bound or a lower bound.
The way in which your proposal could dovetail with RangeExpression is for it to add a requirement to that protocol named `clamping(_:)`. Each type of range (_, closed, countable, countable closed, partial from, partial up to, etc.) would then implement that requirement. Then, implementations of `clamped(to:)` could call `clamping(_:)`. Although, at that point, it would be an open question whether having both clamped(to:) and clamping(_:) would be useful. I would be inclined to think that at most one of these is necessary, and only the latter is compatible with a protocol-based approach. I remain unconvinced, however, that this API meets the very high bar for standard library inclusion. On Tue, Jun 27, 2017 at 20:57 Nicholas Maccharoli via swift-evolution < swift-evolution@swift.org> wrote: > Swift Evolution, > > I want to thank the community for the previous feedback for SE-0177 > and also address the issue of the proposal being sent back for revisions. > > The current status being "Returned for revisions" reflects the detailed > design section being incomplete and not working against the latest Swift 4 > snapshot. > > Another reason mentioned by Ben Cohen was that the proposal did not take > advantage of `RangeExpression` and take advantage of a generic > implementation. > > This has been added in the "Alternatives Considered" section in the pull > request that > is open now but I personally favor the generic approach despite the added > cost of extending `RangeExpression` enough to make the implementation > possible. > > In short, at this time `RangeExpression` is lacking functionality to > implement `clamp(to:)` > in a generic fashion so if the community is in favor of extending > `RangeExpression` I am > more than happy to go with a generic implementation rather than the > current concrete > implementation that is in the proposal pull request now. > > I have tried to address these issues and expand the proposal in this pull > request here: > > https://github.com/apple/swift-evolution/pull/723 > > Thank you all so much for the feedback and support, I look forward to > exploring where > we can go with this proposal and making Swift 4 the best release yet. > > Forever your Swift Evolution buddy, > > - Nick > > > _______________________________________________ > 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