As an additive proposal, I don't think this would be in scope for the current phase of Swift 4.<br><br>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.<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 29, 2016 at 9:39 PM Nicholas Maccharoli via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">Tim,</div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">The protocol extension alone would be sufficient, but for as long as the global functions</div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">`min` and `max` are still around I thought adding a global clamp function would make</div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">for good symmetry.</div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">I'll write a small draft proposal to illustrate my idea a little better.</div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">What does the community think?</div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)">- Nick </div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><br></div><div class="gmail_default" style="font-family:"comic sans ms",sans-serif;color:rgb(39,78,19)"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 2:25 AM, Tim Vermeulen <span dir="ltr"><<a href="mailto:tvermeulen@me.com" target="_blank">tvermeulen@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What would the point of a free function be if you already have a protocol extension?<br>
<span><br>
> Georgios, Yes lets go with clamp for a name!<br>
><br>
> Pyry, Originally I thought of just adding a global function akin to `min`<br>
> and `max` but I am also<br>
> in favour of adding the above extension to `Comparable`.<br>
> I think having both the global function and the protocol extension for<br>
> `clamp` would be great.<br>
><br>
> - Nick<br>
><br>
><br>
</span><span>> On Thu, Aug 25, 2016 at 9:37 PM, Pyry Jahkola<pyry.jahkola at <a href="http://iki.fi" rel="noreferrer" target="_blank">iki.fi</a>>wrote:<br>
><br>
> > On 25 Aug 2016, at 12:05, Nicholas Maccharoli wrote:<br>
> ><br>
> > I personally see merit in adding a function to bound the value of a<br>
> > variable within a range and think it would be simple to write with the<br>
> > existing implementations of `min` and `max` with something like:<br>
> ><br>
> > public func bounds<T : Comparable>(value: T, _ lower: T, _ upper: T)<br>
> > ->T {<br>
> > return max(lower, min(value, upper))<br>
> > }<br>
> ><br>
> > Does this sound like something the community thinks would be worthwhile to<br>
> > add?<br>
> ><br>
> ><br>
> > I'd welcome that addition. In terms of function interface, I think we can<br>
> > do better than the 3-argument `clamp(x, min, max)` function that is seen<br>
> > in several math libraries.<br>
> ><br>
> > Our ***Range types already have a `clamped(to:)` member function, e.g. here's<br>
> > one for ClosedRange<br>
</span>> > <<a href="https://developer.apple.com/reference/swift/closedrange/1779071-clamped" rel="noreferrer" target="_blank">https://developer.apple.com/reference/swift/closedrange/1779071-clamped</a>>.<br>
<div><div>> > It creates a new range constraining the receiver's bounds within the new<br>
> > bounds given as argument.<br>
> ><br>
> > I think the sensible thing would be to add a similar, and equally named,<br>
> > method to the Comparable protocol, taking in the ClosedRange<Self>to<br>
> > limit the value to:<br>
> ><br>
> > extension Comparable {<br>
> > public func clamped(to limits: ClosedRange<Self>) ->Self {<br>
> > return self<limits.lowerBound ? limits.lowerBound<br>
> > : self>limits.upperBound ? limits.upperBound<br>
> > : self<br>
> > }<br>
> > }<br>
> ><br>
> > (-0.1).clamped(to: 0 ... 1) // 0.0<br>
> > 3.14.clamped(to: 0 ... .infinity) // 3.14<br>
> > "foo".clamped(to: "a" ... "f") // "f"<br>
> > "foo".clamped(to: "a" ... "g") // "foo"<br>
> ><br>
> > From my experience, I'd say it'd be most useful for clamping<br>
> > floating-point numbers and collection indices.<br>
> ><br>
> > — Pyry<br>
><br>
><br>
> </div></div></blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>