сейчас попробую, спасибо!

или этот черный ящик выдает результаты отдельно а исключения отдельно?

верно, причем есть даже 2 разных источника ошибок

а зачем тогда вообще язык менять было? - а зачем языку понадобилось расширяться на другие платформы?

Вот, например, мне кажется, что nullability это частный случай union types. Т.е. не T подтип T?, а T|null
Несмотря на то, что некоторым кажется что юнион типы не нужны, они все же закрыли бы несколько значимых юзкейсов, вместо того, чтобы делать для каждого свой синтаксис:
- nullability
- catch блок
- seald классы
- лучше интероп с js/ts
Вот, например, об интеропе с js/ts никто не думал когда проектировал Kotlin. А теперь оно надо. И чтобы он был нормальный приходится все же смотреть на другой язык.

Вот тогда у вас проблема. до 1.4, насколько я понимаю, нет возможности собрать Result руками и вернуть его из функции. Но я с этим не работал, так что лучше чтобы знающие люди подсказали.

ну я больше в ознакомительных целях с этим разбираюсь, так то везде атрибуты намекают что интерфейс может поменяться :)

> мне кажется, что nullability это частный случай union types. Т.е. не T подтип T?, а T|null
Это не всем так кажется. Там Роман свою статью кидал, в ней все есть.

Там много чего сделано для оптимизации.

Можно нужно врубить флажочек

Ну, если уточнить, что T? в Котлине - частный случай union type, то вся остальная часть текста всё ещё остаётся актуальной (что union type скорее нужны, чем нет)

Union type скорее нужны. Так же как и более человечный синтаксис для пересечений (вот единственное, пожалуй, что я бы из Dotty утащил). Но нулябли - это не совсем юнионы с точки зрения использования.

Речь про статью Null is your friend, not a mistake? Так я и не спорю с тем, что проблема nullability существует.
Речь о том, что текущее решение не достаточно общее.

там еще одна, про absense of value

Для нулов? Еще как достаточное. Для сум типов - нет, но это другая проблема

Тут мы опять упираемся в том, что в большинстве языков нулябельность решена через суммы типов. В свое решение, которое ничуть не хуже, а в некоторых случаях значительно лучше. Не надо мешать.

Не для нулов, а для чистоты языка

Чистота языка тут не при чем. В данном случае разделена фича нулябельности и фича сум типов. Это просто выделено в две разные фичи.

Где тут? Я говорю о том, что она (чистота) важна и решения должны максимально общими (в том числе потому что это язык, а не швейцарский нож)

Вот нет. Вы можете решить проблему нулябельности при помощи суммы типов, усложнив синтаксис и затащив довольно тяжелую штуку. Но на самом деле нулябельность встречается примерно в 100 раз чаще, чем сумма типов. Какой смысл гвозди микроскопами забивать?

За тем, что union типы решают не только проблему нуллябельности. Я перечислил то, что как мне кажется, еще они решают:
- catch блок
- seald классы
- лучше интероп с js/ts