I would guess my immediate thought would be to have a clip_left/right or bound_left/right or have a clip/bound with Option args.
Otherwise, I personally most prefer min(a,b) as it is very clear and mathematically standard way of writing things.
Leaving the naming bikeshed aside, I suppose the real question is just how common is this use case for others? Then, can the compiler generate better code with the min_update(x) "in-place" update? Or is it able to optimize the seemingly 2 step process (compute min/max, move/copy the value into storage) all on its own, and do so "reliably". This latter part is akin to the various in-place update std::ops traits.
For me it's common because I'm using mutation a lot. If your Rust code is mostly functional, then it's much less common.
In all or most cases LLVM in release mode is probably able to produce the same code, so it's not an optimization. The purpose of such pair of functions is mostly to make the code more DRY and less bug-prone, reducing the number of tokens of your code, and making your intents more explicit.
Unless you are chaining things in a similar ways to iterators, I don't see how this will reduce significantly in anyway the number of tokens, which is literally 2 tokens less. Also, updating variables with a single function call rather than assignment I don't think it will be more clear to the wider audience. I thought the initial intention was exactpy as vitalyd said for optimising the explicit assignment.
I hear you, but I tend to agree with @Botev that this doesn't appear to be a significant enough win (and some may not even agree it's a win at all). The bar for making this an API in std has to be pretty high, or else everyone's favorite helper functionality is a candidate for inclusion. It seems that you could define your own helper fn/macro that does it for you. Unless this is a widely used pattern by others, I don't think it carries its weight. Just my $.02 of course.