On Tue, 7 Feb 2023 12:53:25 GMT, Tagir F. Valeev <tval...@openjdk.org> wrote:
>> clamp() methods added to Math and StrictMath >> >> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` >> value and safely clamps it to an `int` range. Other overloads work with a >> particular type (long, float and double). Using similar approach in other >> cases (e.g. `float clamp(double, float, float)`) may cause accidental >> precision loss even if the value is within range, so I decided to avoid this. >> >> In all cases, `max >= min` precondition should met. For double and float we >> additionally order `-0.0 < 0.0`, similarly to what Math.max or >> Double.compare do. In double and float overloads I try to keep at most one >> arg-check comparison on common path, so the order of checks might look >> unusual. >> >> For tests, I noticed that tests in java/lang/Math don't use any testing >> framework (even newer tests), so I somehow mimic the approach of neighbour >> tests. > > Tagir F. Valeev has updated the pull request incrementally with one > additional commit since the last revision: > > Comments in tests I would not use `var` with primitive types. You win nothing but may add confusion, as your samples show. There are many cases when implicit type conversion is performed with numeric types, and using `var` could be indeed confusing. In this particular case, you lose nothing, as even if the resulting variable is unexpectedly `int`, you don't lose precision and you don't overflow. If you need to pass it somewhere where `long` is expected, it will be widened without any effort from your side. When you use `var`, you're saying that the type is not that important, and it indeed is. Finally, I find it extremely strange to use `var` to hide the type and name the variable as `longValue2`, encoding the type inside variable name. If the type is important, why don't use an explicit type declaration? ------------- PR: https://git.openjdk.org/jdk/pull/12428
