После это как? ручным вызовом инициализирующей функции?

Да

ну тогда у вас объект до вызова этой функции в невалидном состоянии. Собственно сложно ожидать, что сериализатор будет работать с невалидным состоянием

Почему в невалидном?

потому что неициализированный lateinit - это невалидное состояние

Я, может, к этому полю и обращаться не собираюсь

Вообще использование lateinit для опциональных полей - это как то очень не очень.

ну и тем не менее состояние не валидное. Сериализатор-то расчитывает на то, что вы над языком не издеваетесь

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

А где-то есть правило, что lateinit обязательно должно быть заполнено?

В общем, вот тикет: https://youtrack.jetbrains.com/issue/KT-38951

Есть здравый смысл. Не надо ломать язык. lateinit ломает нулябельность и должен использоваться очень минимально и очень контролируемо.

К слову:
1) Генерируемый сериализатор может проверять KProperty.isInitialized
2) В Jackson ошибка более внятная — там понятно на чём именно она: JsonMappingException: lateinit property description has not been initialized (through reference chain: com.example.LateInitVar["description"])

А как решают такую штуку в сериализации?
Параметр в классе-наследнике добавляет своё поле, а п родит

@Serializable
class Base(val name: String)

@Serializable
class Derived(name: String, val description: String): Base(name)

?

>This class is not serializable automatically because it has primary constructor parameters that are not properties

Рукописный сериализатор делать?
«Не использовать наследование»?
Делать open val?

@Serializable
class Base(open val name: String)

@Serializable
class Derived(override val name: String, val description: String): Base(name)

@Serializable
class Base(val name: String)

@Serializable
class Derived(name: String, val description: String): Base(name)

Как оказалось, override val не работает:

>Serializable class has duplicate serial name of property 'name', either in the class itself or its supertypes

Это ведь, бага?

Завёл https://youtrack.jetbrains.com/issue/KT-38958

Друзья из JetBrains, скажите, а есть чат по райдеру? Бывает натыкаешься на баги, а issue заводить нет времени (тем более, вдруг уже есть?), вот было бы удобно сразу в чат скидывать информацию.

решаю задачки из Kotlin Koans, тут везде в задачах дата классы, функционал которых реализован с помощью функций-расширений в других файлах.
забегая немного вперед хочу спросить, так действительно делается в продакшн коде на котлин или это просто здесь такое упрощение ради задачек?
т.е. что я имею ввиду
есть класс к примеру User у которого там метод void sayHello()

Java:

class User {
    String name;

    void sayHello() {
        System.out.print("hello!");
    }
}

Kotlin:
data class User(var name : String)

и в этом же файле (или в другом, например UserUtils) пишем:
fun User.sayHello() : Unit {
   print("Hello")
}

вот так всегда в котлин принято делать или делают обычно как в Java?

class User {
    String name;

    void sayHello() {
        System.out.print("hello!");
    }
}

Всегда. Дата классы должны содержать только данные, методов с какой либо логикой в них быть не должно.

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

т.е. если я заранее знаю, что какая-то логика, даже минимальная, во взаимодействии с классом будет, то мне его уже точно дата классом не делать?
или отталкиваться от кол-ва функций, которые будут в классе, мол если одна, то тогда помечать класс как data class и эту функцию где-то в другом месте определять, а если условно больше трех, то уже обычным классом делать