4 ms·
Moving into clamp is problematic since you’d make clamp destructive. You couldn’t use any of the arguments after clamp. Non const refs seems like a weird idea
by sesuximo 6y ago
Moving into clamp is problematic since you’d make clamp destructive. You couldn’t use any of the arguments after clamp.
Non const refs seems like a weird idea (what if I got a const ref from my callee? Why can’t I clamp?).
- pbsd 6y agoTrue, but it's entirely voluntary: - clamp(a, b, c), where a, b, c are all l-values would copy everything. Not destructive by default (but wasteful on "big" types). - clamp(a, std::move(b), c) would potentially destroy b, but that's something the caller explicitly opted into. - clamp(a, T{ something }, T{ something else }) would be an implicit move, but nobody is going to accidentally use those r-values anywhere else. The non-const ref version returning is not something I quite like either; it would make more sense to me to have `void clamp(T& x, T const& l, T const& h)`, where the semantics would be more like `x.clamp(l, h);`. But to retain the same API I returned the reference.