Про "в понимании хаскеля" никто ничего не говорил. Про "пошла той дорогой" было конкретно о том, что вместо flow typing там даются новые имена значениям с уточнённым типом только и всего.

Юз кейсы. Нужны юз кейсы. Есть уединенные случае, когда оно выглядит логично, но их действительно очень мало, и как правило они решаются одной лишней строчкой. Я напоминаю, что пункт про то, что "ни нужно" идет только в связке с пунктом "сложно". То есть, если бы это было бесплатно - ОК.

Юзкейсов Роману наверняка предлагали уже больше, чем я за пару месяцев насобираю при всём желании.

Я думаю, что у Бреслава их было еще больше, поскольку он неоднократно говорил, что сам тяготеет к хаскель-стайлу. И тем не менее пока так.

Ну дык я и не против. Если вы заметили, я на протяжении всей беседы стараюсь ни за что не топить. Потому что как только в таких разговорах принимаешь какую-то сторону — начинаются холивары.

У меня очень прагматичный подход. Если есть нужда в чем-то, то должны быть серьезные аргументы для того, чтобы это "купить". Вот юнион тайпы (привет @ilmirus ) - да, безусловно (только если хорошо задизайнить). Self-типы. Тоже скорее да, чем нет (хотя там есть проблемы с совместимостью). Контракты на компаньоны - безусловно в том или ином роде (оно кстати перекрывает львиную долю use cases HKT). Но все это надо обдумать и подружить с существующими фичами. На этом фоне  пат. мат - это чисто эстетическая штука, которая ничего существенного не добавляет (и примеры, где оно таки что-то даст, разумеется будут всем полезны).

У паттерн-матчинга проблема не в том, что его сложно поддержать или он плохо ложится на язык. И то, и то скорее неверно, чем верно. Проблема в нём в том, что его тупо не хватит для того, чтобы было удобно. Он, грубо говоря, зависит от деструктуризации, которая полезна не только в паттерн-матчинге.

А что ты подразумеваешь под деструкторизацией? структурную декомпозицию или избавление от componentN?

Вообще принципиальную поддержку для не только дата классов. Иначе, паттерн-матчинг будет поддерживать только деревья из дата классов, что довольно ограничено.

У меня есть идеи о том, что вместе с велью классами мы могли бы ввести именованную декомпозицию, оставив позиционную только для штук типа кортежей.

Ну то есть де-факто избавление от componentN, тогда там должна быть деструктуризация по имени. Целая история

Ага

Читаю мисли :)

Иногда хочется, чтобы было обе. Что-то вроде:
По имени - ищем проперти, если нету, то можем попытаться найти get(String)
По позиции - ищем componentN, если нету, то можем попытаться найти get(Int)

... Но прямо чтобы это было критично  - не очень часто. Хотя если выбирать из двух, то по имени ощущается полезным чаще.

Вот это вряд ли сработает. get  - это динамический вызов. А componentN доступен во время компиляции. Мы не можем во время компиляции использовать не константные ключи. Деструктуризация по имени - вещь хорошая. И ее вроде даже обсуждали, но там надо сильно долго думать, как это красиво сделать

А в каких-нибудь языках она есть?

В JS есть...

Так а в чём проблема? Либо ты у тебя у get(String) / get(Int) есть конкретный тип, либо ты при деструктурировании его явно указываешь. Тоже самое, что сейчас с componentN (они могут быть с дженерик типом)

Вопрос в том, что может быть в String. И там может быть только константа времени компиляции.

Пока не понял проблемы. Что идеологически компилятору мешает транслировать (тырю частично синтаксис с js, чтобы не думать)

val { abc } = foo

в

val abc = foo["abc"]

?