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

Nicholas Maccharoli nmaccharoli at gmail.com
Wed Jul 19 22:48:12 CDT 2017


Xiaodi,

Sorry for the delay and thanks for replying!

Well, as to if this meets the standard thats something more subjective than
objective so
after hearing a few opinions (hopefully differing) the community could
piece together
a cleaner image of if this is a good idea or not.

>From the previous feedback on the mailing list there were people in favor
and Ben from the
core swift team gave some feedback here saying:

https://github.com/apple/swift-evolution/pull/718

The core team reviewed this proposal and are returning the proposal for
> revision. This is a welcome proposal in principal, but should be revised to
> account for the recent addition of the RangeExpression protocol, in order
> to allow for clamping over different kinds of range expression.



So since the proposal is being "Returned for revisions" I wanted to propose
those revisions here:

https://github.com/apple/swift-evolution/pull/723

- Nick




On Wed, Jun 28, 2017 at 1:13 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> 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/20170720/d0e0de0a/attachment.html>


More information about the swift-evolution mailing list