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

[Xiaodi Wu]

Sorry, it's been a while but I don't understand your reply. As far as I can
tell, nothing has changed since June: the revised proposal continues to
propose an API that is not protocol-based, and the alternative continues to
propose additions to RangeExpression that do not make sense, as partial
ranges do not have both upper and lower bounds.

As I wrote in June, _even if clamping is determined to be a suitable
addition to the standard library_, your revision appears not to address the
core team feedback. I suggested one way in which you could revise your
proposal to address that issue--namely, a `clamping` requirement on
RangeExpression. However, I do not see where you have addressed this
feedback. What am I missing?
On Wed, Jul 19, 2017 at 22:48 Nicholas Maccharoli <nmaccharoli at gmail.com>
wrote:

> 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/5cf9b6b5/attachment.html>