[swift-evolution] [Idea] Add `bounds` function to standard library

[Xiaodi Wu]

As an additive proposal, I don't think this would be in scope for the
current phase of Swift 4.

Looking forward, though, I'm not sure this belongs in the standard library.
In general, my understanding is that Swift's standard library is
deliberately small, and that the criteria for additions are that it's
widely used *and* also non-trivial for the user to write correctly. I've
had to use clamping, obviously, but it's a trivial one-liner that is hard
to write incorrectly. If anything, I'd be in favor of removing max and min
into a future math library outside the standard library.

On Mon, Aug 29, 2016 at 9:39 PM Nicholas Maccharoli via swift-evolution <
swift-evolution at swift.org> wrote:

> Tim,
>
> The protocol extension alone would be sufficient, but for as long as the
> global functions
> `min` and `max` are still around I thought adding a global clamp function
> would make
> for good symmetry.
>
> I'll write a small draft proposal to illustrate my idea a little better.
>
> What does the community think?
>
> - Nick
>
>
>
> On Tue, Aug 30, 2016 at 2:25 AM, Tim Vermeulen <tvermeulen at me.com> wrote:
>
>> What would the point of a free function be if you already have a protocol
>> extension?
>>
>> > Georgios, Yes lets go with clamp for a name!
>> >
>> > Pyry, Originally I thought of just adding a global function akin to
>> `min`
>> > and `max` but I am also
>> > in favour of adding the above extension to `Comparable`.
>> > I think having both the global function and the protocol extension for
>> > `clamp` would be great.
>> >
>> > - Nick
>> >
>> >
>> > On Thu, Aug 25, 2016 at 9:37 PM, Pyry Jahkola<pyry.jahkola at iki.fi
>> >wrote:
>> >
>> > > On 25 Aug 2016, at 12:05, Nicholas Maccharoli wrote:
>> > >
>> > > I personally see merit in adding a function to bound the value of a
>> > > variable within a range and think it would be simple to write with the
>> > > existing implementations of `min` and `max` with something like:
>> > >
>> > > public func bounds<T : Comparable>(value: T, _ lower: T, _ upper: T)
>> > > ->T {
>> > > return max(lower, min(value, upper))
>> > > }
>> > >
>> > > Does this sound like something the community thinks would be
>> worthwhile to
>> > > add?
>> > >
>> > >
>> > > I'd welcome that addition. In terms of function interface, I think we
>> can
>> > > do better than the 3-argument `clamp(x, min, max)` function that is
>> seen
>> > > in several math libraries.
>> > >
>> > > Our ***Range types already have a `clamped(to:)` member function,
>> e.g. here's
>> > > one for ClosedRange
>> > > <
>> https://developer.apple.com/reference/swift/closedrange/1779071-clamped>.
>> > > It creates a new range constraining the receiver's bounds within the
>> new
>> > > bounds given as argument.
>> > >
>> > > I think the sensible thing would be to add a similar, and equally
>> named,
>> > > method to the Comparable protocol, taking in the ClosedRange<Self>to
>> > > limit the value to:
>> > >
>> > > extension Comparable {
>> > > public func clamped(to limits: ClosedRange<Self>) ->Self {
>> > > return self<limits.lowerBound ? limits.lowerBound
>> > > : self>limits.upperBound ? limits.upperBound
>> > > : self
>> > > }
>> > > }
>> > >
>> > > (-0.1).clamped(to: 0 ... 1) // 0.0
>> > > 3.14.clamped(to: 0 ... .infinity) // 3.14
>> > > "foo".clamped(to: "a" ... "f") // "f"
>> > > "foo".clamped(to: "a" ... "g") // "foo"
>> > >
>> > > From my experience, I'd say it'd be most useful for clamping
>> > > floating-point numbers and collection indices.
>> > >
>> > > — Pyry
>> >
>> >
>> >
>>
>
> _______________________________________________
> 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/20160830/57607ae6/attachment.html>