Hi
On 8/28/25 20:26, Kyle Katarn wrote:
Just my opinion but the function aims to provide an alternative to
min(max()) that would be:
- easier to read
- faster to execute
If having many different behaviors depending on an option and so a lot of
if-else path complexity, then it will tend to defeat the second goal. I
Adding an additional parameter to switch between 4 modes of comparison
hardly qualifies as “a lot of if-else path complexity”. That can be done
with a single `switch()` statement. I doubt that you can measure a
meaningful difference in speed and if you can, then it's still possible
to optimize based on the expected path (i.e. closed intervals).
Since a big part of your argument in favor of the clamp() function is
“performance” (both in your reply here and in the introduction to the
RFC): Please add meaningful benchmarks to the RFC text that show how
much faster clamp() is actually going to be compared to alternative
solutions.
would add it if there is a strong interest, otherwise I'd rather stick to a
minimalist implementation (like seen in most languages where clamp() is
available.
Best regards
Tim Düsterhus
