например, System.currentTimeMillis() % 2 == 0

скорее всего часто так но врядли всегда

Почему repeat(20){
Random.nextBoolean()
}
вернет 20 рандомных вариантов

А repeat(20){
Product(...)
}
вернет все объекты со значением false

Если сделать list.map{ it.copy(Random.nextBoolean())}
тогда будут рандомные значения

сделай так
val isVisible: Boolean
 get() = Random.nextBoolean()

ты инициализировал поле класса один раз и далее возвращается значение поля.
Какой результат ты хочешь получить?

Я создаю много объектов класса с рандомным значением, в байт коде там вызов Random.default.nextBoolean() и у всех одинаковое рандомное значение

В таком случае оно же не будет константным

ты подразумевал исходники? (или именно байт-код?)
похоже, что этот Random.default возвращает один и тот же seed

* Сейчас протестил в идее, там работает нормально, а в андроид студии только false значения

Kotlin byte code -> decompile

decompile  показывает исходники

Ну ниче...упорство и труд-все перетрут!

У меня вопрос уровня новичка. Изучаю Котлин, нуллабл типы. Когда вижу код в моб разработке, там всегда дописывают восклицательный знак. Что это за плюшки null safety что приходится  везде дописывать оператор?. Почему не использую не нуль объекты?

Если объект создаётся в конструкторе/init методе, то поле точно получит значение, но в жц андроида вызывается onCreate. Со стороны языка не факт, что он будет вызван, поэтому можно использовать lateinit var, либо вначале объявить как null

Как пример

var flag: Boolean
init{
flag = false
}
Значение будет установлено при инициализации объекта

var flag: Boolean
onCreate(..){
...
flag = false
}
Неизвестно когда вызовется onCreate, поэтому нужно установить значение

Получается это нивелирует преимущество котлин, в том плане, что в джава для нуля не нужно нигде добавлять? А здесь везде ставишь

Можно использовать lateinit var, потому что в случае андроида гарант, что onCreate точно вызовется

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

Стандартный кейс уже выше описали, но он не совсем прозрачный. Если обобщить: в котлине везде надо использовать обычные val/var переменные.

Lateinit на мой взгляд костыль стараюсь использовать его только для di полей.

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

К примеру:
Поставляемая через di  ViewModel может быть lateinit var.

А binding (или ещё callback какие нибудь) nullable, чтобы их очистить в onDestroy/View.
И так как есть контракт их очищения именно там, везде до можно обращаться без проверки !!. Правильно ли это ? Хз, кто то топит за то чтобы было минимум внештатных ситуаций и даже если уверен что не null использовать ? А не !!. С другой стороны топят за !!, так как если есть явный контракт, то пусть лучше упадет и об этом станет известно, чем просто ничего не сделает))) более детально можно в лс спросить если что