Не понял. Ругается и в джаве, и в Котлине? В чём тогда проблема?

Да. У моей инспекции фикса пока вообще нет.

Вообще это тонкий момент. Люди любят параметризовать свой код чем-нибудь типа val debug = true и потом бранчеваться по этому условию. И ты опять же скажешь, что это плохо. Но нам надо поддерживать все популярные стили написания кода, а не только твой. Поэтому выдавать тут кучу предупреждений не представляется возможным.

Кажется, это другая инспекция, которая конкретно разворачивает if(true)/if(false) и больше ничего

Ну ещё раз говорю - это должна быть отдельная паттерновая инспекция, а не датафлоу.

Так-то даже случаи когда конфликт со смарткастом обычно можно переписать таким образом, что код станет проще и понятнее и конфликт исчезнет. Но это часто думать надо и автоматический фикс мы точно не сможем предложить. А человек не будет думать сам, он инспекцию отключит, если не может быстро исправить варнинг. Потому и говорю, что инспекцию надо глупее делать.

Так и знал, что ты к этому придерёшься. Даже написал, что пример искусственный, но не помогло :-) isNullOrEmpty анализатор не распознаёт (по крайней мере пока).

Получается, кто-то там может слать недопустимые значения, а мы их игнорируем.

Ну ты зануда. Ну представь, что там исключение кидается. Лучше будет?

просто исходно код выглядит стрёмно

Бывает и похуже, чего уж там. Если ругаться на весь код выглядящий стрёмно, никто не будет пользоваться статическим анализом. В данном случае сила инспекции в том, что она находит реальные баги, очень крутые и вкусные. Будет обидно, если они потонут в куче левых предупреждений.

Твой встроенный оптимизатор отлично работает! А теперь придумай мне короткий пример, чтобы let был оправдан :-)

А зачем в updatePriority примере нужен был if?

Проблема уменьшенных примеров во всей красе. Например, перед when могло быть общее действие, которое надо сделать для всех трёх вариантов. Давай что-нибудь добавлю.

command.startsWith("--data", ignoreCase) -- тоже по делу ругалось

Например, у тебя двадцать вызовов с этим ignoreCase. И ты хочешь подчеркнуть, что он во всех вызовах одинаковый. Во всяком случае, если ты считаешь, что заводить переменную здесь не надо (а не все с тобой согласятся), то это отдельная стилистическая инспекция "лишняя переменная", она должна ругаться именно на это с предложением заинлайнить и не должна быть привязана к типу переменной.

Я тут узнал, что

а) Люди часто её включают не в настройках, а временно прямо из completion popup (там есть выпадающее меню) и забывают выключить

б) Делают это для знакомства с новым API. Пишешь имя объекта, точку и изучаешь, какие вообще в нём есть методы. Можно ещё по Ctrl+Q джавадок открыть в окошке рядом, очень удобно. В этом случае алфавитный список кажется удобнее.

Yes, see JLS 4.2.3:

The floating-point types are float and double, which are conceptually associated with the single-precision 32-bit and double-precision 64-bit format IEEE 754 values and operations as specified in IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985 (IEEE, New York).

Нет, не сойдёт.

В плане и перформанса, и читабельности в Java, разумеется, надо использовать метод стандартной библиотеки, а не изобретать велосипед. Статья не предполагает, что написание такого метода вам необходимо для вашего сурового энтерпрайза. Статья помогает разобраться во внутреннем устройстве вещей, которые нас окружают.

Ну это из разряда проверять истинность булевой переменной через String.valueOf(myFlag).length() == 4. Работает, конечно, вопросов нет. Может есть языки, где такой подход идиоматичен.

Как хранится - это личное дело виртуальной машины. В спеке описано поведение. Поведение соответствует IEEE-754 с некоторыми упрощениями (например, никаких signalling NaN нету).

(DoubleConsts.EXP_BIT_MASK | DoubleConsts.SIGNIF_BIT_MASK) докрутит javac. Это по стандарту константа времени компиляции, она уже в байткод ляжет в виде конкретного числа. А вот сделать инлайнинг, подставить параметр sign и вычислить (Double.doubleToRawLongBits(sign) & (DoubleConsts.SIGN_BIT_MASK) до константы 0 и удалить - уже задача JIT-компилятора (вполне посильная).

Так это решение абсолютно платформонезависимо! А copySign внутри сделает то же самое. Возможно, JIT даже докрутит ваш вариант до моего.

Это ужасно медленно. Невообразимо медленно. Может сотни наносекунд занять.

Java вообще не так работает. В JNI методе можно оно и так, только на сам JNI оверхед будет не меньше сотни наносекунд.

Там не всё так просто. Когда этот тикет появился, с интринсиками дела обстояли туго, и всякие doubleToRawLongBits были реально медленными, поэтому такое изменение не имело смысла. Потом времена изменились.