История изменений

У Optional есть один минус.

Ровно тот же минус есть и в подходе с обеспечением null safety через создание особых случаев. Ведь:

А его обход, например, в kotlin виден сразу — для этого используется очень уродливый постфиксный оператор "!!"

Уродливость оператора — это категория, приходящая с опытом. Для гипотетического джуниора это ничем не отличается от вызова get опционального значения. И точно так же требует поправки на code review.

Для начала про Rust — там, по сути, мы тоже имеем _почти_ Type Level Null Safety, нужно постараться, чтобы вставить null, он не является в явном виде частью языка. Не совсем идеально, но тоже очень хорошо с учетом необходимости сохранения null для FFI.

Вообще же, например, в Scala, я упоминал еще, что можно не просто написать Option.get(), можно просто не вернуть Option, а вернуть сырой объект (или null) из метода. :)

И в итоге — либо все оборачивать в Option, даже если не nullable, либо где-то не оборачивать и тогда каждый раз при использовании думать — там действительно not nullable или просто обернуть забыли? Или не обернули специально, а потом отрефакторили кусочек метода и не заметили, что теперь он может вернуть null?

А так — null *уже* сам по себе является особым случаем — объект может быть двойственного типа и иметь кардинально разное поведение.

Дальше нужно «или крестик снять, или —».

Если мы добавляем Option, давайте реально полностью убирать null — ну хотя бы как в Rust (все же совместимость нужно сохранять), только, лучше, еще более жестко. Вон, как в C# Unsafe делали в свое время — и в блок специальный выделить участок кода нужно, и флаг компилятора вставить — десять раз подумаешь, нужен ли этот геморрой.

Если мы оставляем null как особый случай — давайте не Option ставить, а Nullable Types. Option в таком случае хуже — дает меньше гарантий.

Если в языке нет null, то не будут. Опять же воспользуюсь случаем и сошлюсь на Rust. Там это очень грамотно реализовано.

Про rust — согласен. Но в большинстве остальных языков есть одновременно и Option, и null — это плохо.

У Optional есть один минус.

Ровно тот же минус есть и в подходе с обеспечением null safety через создание особых случаев. Ведь:

А его обход, например, в kotlin виден сразу — для этого используется очень уродливый постфиксный оператор "!!"

Уродливость оператора — это категория, приходящая с опытом. Для гипотетического джуниора это ничем не отличается от вызова get опционального значения. И точно так же требует поправки на code review.

Для начала про Rust — там, по сути, мы тоже имеем _почти_ Type Level Null Safety, нужно постараться, чтобы вставить null, он не является в явном виде частью языка. Не совсем идеально, но тоже очень хорошо с учетом необходимости сохранения null для FFI.

Вообще же, например, в Scala, я упоминал еще, что можно не просто написать Option.get(), можно просто не вернуть Option, а вернуть сырой объект (или null) из метода. :)

И в итоге — либо все оборачивать в Option, даже если не nullable, либо где-то не оборачивать и тогда каждый раз при использовании думать — там действительно not nullable или просто обернуть забыли? Или не обернули специально, а потом отрефакторили кусочек метода и не заметили, что теперь он может вернуть null?

А так — null *уже* сам по себе является особым случаем — объект может быть двойственного типа и иметь кардинально разное поведение.

Дальше нужно «или крестик снять, или —».

Если мы добавляем Option, давайте реально полностью убирать null — ну хотя бы как в Rust (все же совместимость нужно сохранять), только, лучше, еще более жестко. Вон, как в C# Unsafe делали в свое время — и в блок специальный выделить участок кода нужно, и флаг компилятора вставить — десять раз подумаешь, нужен ли этот геморрой.

Если мы позволяем null (как Scala, например) — то Option хуже чем nullable types — дает меньше гарантий.

Если в языке нет null, то не будут. Опять же воспользуюсь случаем и сошлюсь на Rust. Там это очень грамотно реализовано.

Про rust — согласен. Но в большинстве остальных языков есть одновременно и Option, и null — это плохо.

У Optional есть один минус.

Ровно тот же минус есть и в подходе с обеспечением null safety через создание особых случаев. Ведь:

А его обход, например, в kotlin виден сразу — для этого используется очень уродливый постфиксный оператор "!!"

Уродливость оператора — это категория, приходящая с опытом. Для гипотетического джуниора это ничем не отличается от вызова get опционального значения. И точно так же требует поправки на code review.

Для начала про Rust — там, по сути, мы тоже имеем _почти_ Type Level Null Safety, нужно постараться, чтобы вставить null, он не является в явном виде частью языка. Не совсем идеально, но тоже очень хорошо с учетом необходимости сохранения null для FFI.

Вообще же, например, в Scala, я упоминал еще, что можно не просто написать Option.get(), можно просто не вернуть Option, а вернуть сырой объект (или null) из метода. :)

И в итоге — либо все оборачивать в Option, даже если не nullable, либо где-то не оборачивать и тогда каждый раз при использовании думать — там действительно not nullable или просто обернуть забыли? Или не обернули специально, а потом отрефакторили кусочек метода и не заметили, что теперь он может вернуть null?

А так — null *уже* сам по себе является особым случаем — объект может быть двойственного типа и иметь кардинально разное поведение.

Дальше нужно «или крестик снять, или —».

Если мы добавляем Option, давайте реально полностью убирать null — ну хотя бы как в Rust (все же совместимость нужно сохранять), только, лучше, еще более жестко.

Если мы позволяем null (как Scala, например) — то Option хуже чем nullable types — дает меньше гарантий.

Если в языке нет null, то не будут. Опять же воспользуюсь случаем и сошлюсь на Rust. Там это очень грамотно реализовано.

Про rust — согласен. Но в большинстве остальных языков есть одновременно и Option, и null — это плохо.