Feature #14784

Comparable#clamp with a range

Added by zverok (Victor Shepelev) over 2 years ago. Updated 11 months ago.

Target version:



Allow "one-sided" clamp to limit only upper bound (and, ideally, only lower too).

Proposed implementation: allow clamp(begin..end) call sequence (without deprecating clamp(begin, end)), to take advantage from open-ended ranges with clamp(begin..).

Reasoning about range

I looked through #clamp discussion, but couldn't find there why syntax clamp(b, e) was preferred to clamp(b..e). The only one I could think of is possible confuse of how clamp(b..e) and clamp(b...e) behaviors should differ.

The problem becomes more important with the introduction of open-ended ranges. I believe this is pretty natural:

some_calculation.clamp(0..)    # now, I use clamp(0, Float::INFINITY)
timestamp.clamp(  # now, I typically use clamp( with custom defined constant


  1. This is "one-sided", you can't do clamp( To this I can answer than from my experience "clamping only minimum" is more frequent, and if you need to clamp only maximum, most of the time there is some "reasonable minumum". Another idea is that maybe this is a proof why "start-less" ranges are necessary, after all, doubted here
  2. Why not just leave current clamp(b, e) and allow clamp(b)? Answer: because when you see clamp(10), is it clamp(10, nil), or clamp(nil, 10) (yes, logically it is the first argument that is left, but from readability point of view it is not that obvious). Possible alternative: clamp(min: 0, max: 10), where you can omit any of two.
  3. Why do you need one-sided clamp at all? Because alternatives is much more wordy, making reader think:
# with clamp

# without clamp
v = chain.of.calculations
v < 0 ? 0 : v

# or, with yield_self (renamed to then)
chain.of.calculations.then { |v| v < 0 ? 0 : v }

Both alternatives "without #clamp" shows intentions much less clear.

Also available in: Atom PDF