не подкажете что не так?

вроде и потокобезопасно, и значение инициализируется

https://t.me/horsecups/194129

Локальная переменная нуллабельного типа M?, а нужно вернуть M.

так если она null то метод transformMetadata(dataStream.getMetadata()) её инициализирует

вроде слышал что анализатор кода котлина должен такое понимать

точнее компилятор

Мда, интересно. Можно попробовать лапшу вроде return metadata ?: transform...(...).also { metadata = it }

вроде и потокобезопасно, и значение инициализируется

Что потокобезопасно?

сама конструкция

если написать так: if (metadata == null) { metadata = transformMetadata(dataStream.getMetadata()) } return metadata

А вообще, видится мне, что вместо всей этой констркции можно использовать lazy. Там и потокобезопасная публикация будет.

то после инициализации, но перед возвратом, значение могут обнулить в теории из другого потока

а с локальной переменной такой проблемы нет

Есть другая: несколько потоков могут запустить transformMetadata и обновлять поле metadata под гонкой.

Поэтому если там реально многопоточка, лучше использовать AtomicReference или AtomicFieldUpdater.

это может быть, но к NPE это привести не сможет

нене, пока на многопоточность можно забить

Повторюсь, видится мне, что тут можно взять lazy

тут просто странно, очевидно корректный код - а компилятор не может понять что все ОК

Джун — это человек, который хорошо знает язык+стдлиб. Мид может разработать что-то годное. Сениор — спроектировать и разработать что-то большое, шустрое, надёжное.

Почти согласен, но этого реально многовато для Джуна. В основном, понимание многих тонкостей приходит со временем и опытом.

А у Джуна, обычно, опыта не так много

тут просто странно, очевидно корректный код - а компилятор не может понять что все ОК

Подтверждаю, написал такой же код, та же ошибка. kotl.in/issue

кто-то заведет багу, или мне завести?

ха-ха. Если поставить M : Any, то смарт-каст происходит.

Но, тем не менее, это баг.

Всё кастуется нормально

Может kotlin надо обновить?

<kotlin.version>1.2.10</kotlin.version>

Может kotlin надо обновить?

Нет, это прокатывает только с нуллабельным type-параметром

хм. проверил, у меня со String та же фигня

А, да, действительно, попробовал с T, не кастится

кажется, понятно почему такое может быть

а не. со String норм

abstract class SomeClass<out T : Any>

вот так всё нормально

кастуется

иначе T (в примере M) может быть nullable типом

в kotlin out T по умолчанию будет унаследовано от Any?

иначе T (в примере M) может быть nullable типом

да

в kotlin out T по умолчанию будет унаследовано от Any?

кажется, таки от Any?

в kotlin out T по умолчанию будет унаследовано от Any?

тут не очень понятно. это вопрос или утверждение :)

кажется, таки от Any?

да, именно так и написал, хз почему телеграмм неправильно подсветил)

вот, хотя бы на такое исправил

и подсветка сразу починилась )

не совсем понял. это таки баг или нет?

нет. просто в твоём случае класс M был унаследован от nullable Any

abstract class SomeClass<out T : Any>

? при таком объявлении смарткаст происходит правильно

а можно на пальцах сценарий когда словим NPE, если не указывать out M

не совсем понял. это таки баг или нет?

Это баг. В последней строке res гарантировано M, вне зависимости от того, нуллабельно M или нет.

Указать надо не out M, а : Any весь фокус именно здесь. Твой тип M допускал Any?, поэтому даже в результате смарткаста всё равно мог получиться nullable тип; в моём варианте nullabillity не допускается что и позволяет сделать смарт-каст правильно;

Указать надо не out M, а : Any весь фокус именно здесь. Твой тип M допускал Any?, поэтому даже в результате смарткаста всё равно мог получиться nullable тип; в моём варианте nullabillity не допускается что и позволяет сделать смарт-каст правильно;

val res = metadata if (res != null) { return res } вот так же у меня смарткаст работает

не вижу принципиальной разницы.

Указать надо не out M, а : Any весь фокус именно здесь. Твой тип M допускал Any?, поэтому даже в результате смарткаста всё равно мог получиться nullable тип; в моём варианте nullabillity не допускается что и позволяет сделать смарт-каст правильно;

Какая разница, нуллабельно ли res, если оно гарантировано M?

хотя да. если M нулабельно, то какая разница это M или "M?" ?

чет я запутался

если переменная M может принимать значение null, то пропадает смысл разделять "M" и "M?"

? мой вариант не позволяет вернуть null из класса наследника

а если без out?

? твой вариант позвоялет вернуть null, хотя transform и объявлен как T

out здесь не при чём

кинь код пожалуйста не картинкой

abstract class SomeClass<T> { private var metadata: T? = null fun getSmth(): T { var res = metadata if (res == null) { res = transform() metadata = res } return res } abstract fun transform(): T } class Abv : SomeClass<String?>() { override fun transform(): String? { return null } }

спасибо

ERROR: S client not available

это твой вариант. у тебя может случиться NPE после transform()

тоесть компилятор "Бдит" чтобы getSmth() не вернул null, но в то же время спокойно разрешает вернуть null из transform()

хотя оба возвращают T

и кстати если у меня у наследника T = String? то null это корректное значение для getSmth()

тоесть компилятор "Бдит" чтобы getSmth() не вернул null, но в то же время спокойно разрешает вернуть null из transform()

если ты скажешь, что class Abv : SomeClass<String>, то из transform нельзя будет вернуть null

да, но мы же сейчас о случае с "String?"

тоесть компилятор "Бдит" чтобы getSmth() не вернул null, но в то же время спокойно разрешает вернуть null из transform()

ну отслеживать все теоретические переопределения компилятору уже не под силу))

тогда можно, да. ибо null — допустимое значение типа String?

и кстати если у меня у наследника T = String? то null это корректное значение для getSmth()

нет.

почему?

У тебя же возвращаемый тип T, а не T?. А типы в котлине устроены так что T? это предок T. Поэтому кастовать от nullable к non-nullable можно, а вот в обратную сторону уже нельзя

как можно скастовать собаку к животному, но не животное к собаке

а как сюда в чат вставить форматированный код?

три `

три символа '`'

спс

abstract class SomeClass<T> { private var metadata: T? = null open fun getSmth(): T { var res = metadata if (res == null) { res = transform() metadata = res } return res } abstract fun transform(): T } class Abv : SomeClass<String?>() { override fun getSmth(): String? { return null } override fun transform(): String? { return null } }

вот так вполне легально , в переопределенном методе возвращаем null

нет

для компилятора open не гарантия того что его кто-то переопределит

тип T может быть nullable

он позволил так переопределить. значит и в базовом легален null

поэтому в теории возможна ситуация в которой я просто не переопределю метод getSmth но параметром у меня будет nullable

и система типов поломается

он позволил так переопределить. значит и в базовом легален null

но не компилируется же

в базовом классе всё равно же есть место для ошибки

abstract class SomeClass<T> { private var metadata: T? = null open fun getSmth(): T { var res = metadata if (res == null) { res = transform() metadata = res } return res as T } abstract fun transform(): T } class Abv : SomeClass<String?>() { override fun getSmth(): String? { return null } override fun transform(): String? { return null } }

вот так компилируется. а на самом переопределении - не ругается

только пишет Unchecked cast: T? to T

типа может поломаться в рантайме и сам себе злой буратино будешь)

логика такая. есть 2 варианта развития событий: 1) если T - не nullable, то transform() не может вернуть null, значит и getSmth() Тоже не может вернуть null 2) если T - nullable , то transfrom() тоже может вернуть null, но тогда и getSmth() должен тоже "мочь" вернуть null , т.к. в обоих методах возвращаемое значение T - nullable, и всякое различие между "T" и "T?" стирается и не имеет смысла. вот допутстим далее идет такой код abstract class SomeClass<T> { private var metadata: T? = null open fun getSmth(): T { var res = metadata if (res == null) { res = transform() metadata = res } return res as T } abstract fun transform(): T } class Abv : SomeClass<String?>() { override fun getSmth(): String? { return null } override fun transform(): String? { return null } } class C { init { val a = Abv() println(a.getSmth().length); // <-- ошибка! } } все равно тут нужно проверять на null, а значит не важно что реализация getSmth() пытается "защитить" от возврата null - от этой защиты все равно нет толку

Ну так подожди. В последнем примере ты явно создаёшь объект класса с дженериком nullable типа. Конечно же он сможет вернуть null, о чём тебе ide и говорит когда ты вызываешь length.