`int.clamp` and `float.clamp` in some case could be seen as misleading

[NNBnh]

Currently the inner work of the function are:

/// Restricts a number between a lower and upper bound.
///
pub fn clamp(x, min min_bound, max max_bound) {
  x
  |> min(max_bound)
  |> max(min_bound)
}

You can view it fully in:

• int.clamp's code.
• float.clamp's code.

But if the user mix the min and the max:

clamp(10, min: 20, max: 5)
// -> 20 (which is violate the `max_bound` of `5` and could be seen as misleading).

And the clamp in the current implement could arguably be seen as bloat too, because if the use wants the behavior of the current clamp, they just need to x |> min(b) |> max(a), not much longer than x |> clamp(a, b).

Suggestion

I think we should change the function to:

/// Restricts a number between two bounds.
///
pub fn clamp(x, first first_bound, second second_bound) {
  case first_bound >= second_bound {
    True -> x |> min(first_bound) |> max(second_bound)
    False -> x |> min(second_bound) |> max(first_bound)
  }
}

This implement should be more correct-ness and convenient for the user who want this behavior.

An alternative naming of arguments could be pub fn clamp(x, from from_bound, to to_bound) or pub fn clamp(x, start start_bound, stop stop_bound) if this is more fitting to the lib.

If this got accepted, I would love to make a PR for this proposal.

[pangeorg]

Hi! Coincidentally, I started a discussion about something similar in the .net runtime repo: runtime. It seems that typical graphics libraries like HLSL bascially handle this case like it is implemented in gleam :)

[lpil]

Ah! Really good investigation, thank you.

I think the current behaviour for negative numbers is a bug. It's confusing, and it's not a documented behaviour. Let's correct it the way you have suggested there!