Проверка JSON до размеченного объединения

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

Функция, которая сопоставляет Right _ и возвращает True, примет Right undefined, ни разу не тронув полезную нагрузку. Попросите length этой нагрузки, и вычислению она понадобится, а там и случится сбой. А let loop = loop in loop можно дать тот же тип, и он не дойдёт ни до одного конструктора.

Так что под вашим разделением проверки входа и представления вариантов в Haskell лежит ещё один слой. Декодер может быть прав, тип точен, а вызывающий код всё равно потребует значение, которого нет. Форма результата известна, если вычисление до него дойдёт.

Добавим Deferred(ticket) третьим вариантом и посмотрим, куда расползётся изменение. Закрытый enum в Scala 3 даёт этому случаю собственные данные, и это удобно. Но меняется декодер, а за ним все потребители, включая отрисовку и сохранение. Пока все варианты принадлежат одной модели, такая согласованность окупается.

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

Что здесь означает отсутствие ticket? Пропущенный или null тикет может значить битый ответ. А может значить принятую отсрочку без номера для отслеживания. String? в Kotlin хотя бы покажет, что значения может не быть, но не скажет, какой из двух случаев перед нами. Оставьте поле допускающим null, и каждый потребитель Deferred(ticket) будет решать это по-своему. Эту границу я бы обозначил явно, прежде чем добавлять случай.

Для этого расширения это битый ответ. deferred требует, чтобы ticket присутствовал и был непустой строкой. Пропущенное свойство не проходит декодирование, null тоже, "" тоже. Это правило приёма, и живёт оно в декодере, рядом с проверкой метки.

У пустого случая, который обычно хотят, уже есть место. ready с items, равным [], означает, что запрос завершился без элементов. Это настоящий результат. Отсрочка без тикета означает другое, и заимствовать эту форму ей незачем.

Если сервис потом разрешит отсрочку без отслеживания, это будет новый вариант со своим именем и своей заметкой для вызывающего кода. Чего я не хочу, так это тихо собирать Deferred из отсутствия, потому что поле оказалось необязательным. Пока протокол меняется, отдельный вариант дёшево добавить и дёшево убрать.

Можно, наверное, вообще не пускать отклонённые тикеты в объединение. Если декодер возвращает Result<Response, ParseError>, они остаются на стороне ошибки, и вызывающий код сообщит об ошибке декодирования, не создавая ни Deferred, ни пустой Ready. Проверять вход по-прежнему должен декодер. Тип результата просто даёт сбою место, куда пойти.