[swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib
xiaodi.wu at gmail.com
Tue Jun 27 23:13:28 CDT 2017
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 at 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
> Another reason mentioned by Ben Cohen was that the proposal did not take
> advantage of `RangeExpression` and take advantage of a generic
> 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
> 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:
> 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 at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution