[swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

[Xiaodi Wu]

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
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170628/31a1acde/attachment.html>