Так это можно все сделать в одном sealed

Зачем дробить. Хотя тут уже нужно конкретные кейсы смотреть

Мне нравится подход который сделан в библиотечке better-parse (такое можно писать там где оно нужно, незачем делать универсальный подход который в специфических ситуациях будет выглядить криво):

sealed class ParseResult<out T>
data class Parsed<out T>(val value: T): ParseResult<T>()
abstract class ErrorResult : ParseResult<Nothing>()

чуть что и расширить можно своими ошибками

всем привет, подскажите плз с циклами
на java нет проблем, а вот пишу на котлин и массив выходит за границы


  for (i in 0 until mBoardView.columnCount) {
                   for (j in 0 until mBoardView.getAdapter(i).itemList.size) {
                       val taskNewPos = mBoardView.getAdapter(i).itemList[j]

Ну причина простая - иногда очень удобно иметь разметку, какой тип главный, а какие побочные. Either ровно это проблему и решает. Т.е. например без такой разметки надо с нуля переизобретать достаточно удобные вещи вроде map/flatMap какого-нибудь.

for (taskNewPos in mBoardView.getAdapter(i).itemList) {

?

что непонятно?

а, не, мне нужно это значение дальше

непонятно почему 0 until…, а не просто for(taskNewPos in …)

Если нужен индекс, то

for ((index, value) in mBoardView.getAdapter(i).itemList.withIndex()) {
   println("The element at $index is $value")
}

ща попробую, спасибо

Или на другой лад
mBoardView.getAdapter(i).itemList.forEachIndexed { j, value ->

Мне кажется это больше к java относится. Там нет null safety, поэтому невозможно отличить ситуацию null потому что баг, или null потому что так задумано.
А в котлине явно указывается нулябельное значение или не нулябельное. Поэтому если указан нулябельный тип, то это именно смысловая нагрузка: с точки зрения бизнес логики вот эта штука может отсутствовать.

Я именно не про ошибку в коде, а null как осмысленное значение. Дополнительной информации null нести не может, только представлять один вариант развития событий.

в смысле что хочется не просто знать что отсутствует, но и какую то дополнительную информацию, типа почему отсутствует?

Ну в случае с отсутствием обычно не важно почему. Но какая-нибудь другая ошибка может содержать дополнительную информацию. Или их может быть несколько.
И вот тут-то уже надо sealed class.

как сделать функцию с дженерик констреинтом?(нужно чтобы дженерик был Comparable)

В системе сообщения обрабатываются последовательно в один поток. Делаю с помощью актора и его канала.

При этом, скажем есть типы А B C
И событие B - я его мог бы обрабатывать пачкой. Типа List<B>.  (Этот B - он у меня немного особенный. Его время обработки не зависит от количества обрабатываемых В. Мало того, эти В изначально (это события от удаленных устройств) идут невпопард и с большой задержкой. Так что еще одна задержка в самой системе не принципиальна )

Могу ли я как то собрать в List последовательные события B?
Или могу ли я глянуть в список событий и понять, что я хочу сейчас отработать - все события B или A, С по одному.
Или может какой то приоритет?

Пока получилось вот так https://pl.kotl.in/qVLE7N2RD
Но я не уверен что это корректный вариант.