.min(x).max(y) with x < y

[JarredAllen]

What it does

Lints against people using min and max methods (on the float types or on Ord) to constrain a value to a range, but getting the arguments to min and max backwards (such that the argument to min is less than the argument to max). In that case, instead of clamping the value to be between the two arguments (likely what was intended), it will always return the argument of the second function called.

Categories (optional)

• Kind: correctness

Drawbacks

None. If someone wanted the result of the expression this lint triggers on (which is unlikely), they could just include the returned value directly.

Example

Given a floating-point variable x:

x.min(-1.0).max(1.0)

will always give the value 1.0, whereas

x.max(-1.0).min(1.0)

will give the value of x, clamped between -1.0 and 1.0, with 1.0 for NaN.

[flip1995]

Should the suggestion be to swap the min and max functions or to swap their arguments (i.e. -1.0/1.0)? I'm leaning towards the latter.

[JarredAllen]

The two options are equivalent, behavior-wise, except when working with floats if NaN is passed in (calling either function on NaN returns the argument, so the first parameter will be the result in that case). It might be better to keep the arguments and swap the functions, in case the code was written with which value NaN becomes in mind, though I don't know if that's a common enough occurrence to worry about. I've never written or seen code which clamps a float which might be NaN and cares about what value it becomes, but I wouldn't be surprised if it exists.

[flip1995]

I would go for changing the order of the functions in that case. That way, we can guarantee to always emit a semantic equivalent suggestion.