There is already a `clamped` function for clamping one range to another and I
feel that this function should be consistent with that one. As I see it, it can
either be consistent in that it takes a Range as its argument, or in being an
extension to Range. Probably something like either one of these:
extension Comparable { // or something else?
func clamped(to range: Range<Self>) -> Self
}
extension Range {
func clamping(_ value: Bound) -> Bound
}
Involving a range is good because that means that ensuring that the bounds
checking (lower < upper) is already taken care of.
I do feel that this a useful addition to the standard library. But it is purely
additive, so it should wait until after Phase 1.
- David
Sent from my iPad
> On 2 Sep 2016, at 18:55, Nicholas Maccharoli via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Introduction
>
> The aim of this proposal is to introduce clamp functionality to the swift
> standard library. The clamp function would take a value and a upper and lower
> bounds to clamp the value to, ensuring that the return value of the function
> is within the range specified by the upper and lower bounds. Swift-evolution
> thread: Discussion thread topic for that proposal
>
> Motivation
>
> The standard library already includes functionality for min and max but at
> the time of this writing there is no global function for clamp. Adding a
> clamp function would complement min and max really well and would also
> eliminate the need for developers to write their own clamp functionality.
>
> Proposed solution
>
> I propose that a global clamp function akin to min and max be added to the
> standard library.
>
> Detailed design
>
> The implementation of the global clamp function would be as follows:
>
> public func clamp<T : Comparable>(value: T, _ lower: T, _ upper: T) -> T {
> return max(lower, min(value, upper))
> }
> Impact on existing code
>
> There are no impacts on existing code, this proposal is purely additive.
>
> Alternatives considered
>
> Aside from not making the additions that this proposal wishes to make to the
> standard library no other alternatives have been considered.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
