Телеграмм чат группы kotlin

Поцоны и поцонессы посоветуйте, мигрируем на котлин 14 и словили такую штуку, на которую 13-й не ругался. Ну и по виду если флоу смотреть то вполне норм должно быть. Стоит заводить ишу аль нет?

import kotlin.random.Random

fun main(args: Array<String>) {
    var enumVar: SomeEnum? = null
    val result = if (Random.nextBoolean()) {
        "result"
    } else {
        enumVar = try {
            SomeEnum.valueOf("X")
        } catch (e: Exception) {
            throw RuntimeException()
        }
        enumVar!!.name // !!! HERE NOW it should be null-asserted
    }
    print(enumVar)
    print(result)
}

enum class SomeEnum {
    FOO, BAR
}

Бамп

источник

14:12пожаловаться #9

AM

Andrew Mikhaylov in Kotlin Community

Constantine Linnick

Поцоны и поцонессы посоветуйте, мигрируем на котлин 14 и словили такую штуку, на которую 13-й не ругался. Ну и по виду если флоу смотреть то вполне норм должно быть. Стоит заводить ишу аль нет?

import kotlin.random.Random

fun main(args: Array<String>) {
    var enumVar: SomeEnum? = null
    val result = if (Random.nextBoolean()) {
        "result"
    } else {
        enumVar = try {
            SomeEnum.valueOf("X")
        } catch (e: Exception) {
            throw RuntimeException()
        }
        enumVar!!.name // !!! HERE NOW it should be null-asserted
    }
    print(enumVar)
    print(result)
}

enum class SomeEnum {
    FOO, BAR
}

Как по мне, стоит. Я не вижу, что могло бы поменять переменную -- её никто не захватывает.

источник

14:14пожаловаться #10

QH

Quantum Harmonizer in Kotlin Community

Constantine Linnick

Поцоны и поцонессы посоветуйте, мигрируем на котлин 14 и словили такую штуку, на которую 13-й не ругался. Ну и по виду если флоу смотреть то вполне норм должно быть. Стоит заводить ишу аль нет?

import kotlin.random.Random

fun main(args: Array<String>) {
    var enumVar: SomeEnum? = null
    val result = if (Random.nextBoolean()) {
        "result"
    } else {
        enumVar = try {
            SomeEnum.valueOf("X")
        } catch (e: Exception) {
            throw RuntimeException()
        }
        enumVar!!.name // !!! HERE NOW it should be null-asserted
    }
    print(enumVar)
    print(result)
}

enum class SomeEnum {
    FOO, BAR
}

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

источник

14:15пожаловаться #11

CL

Constantine Linnick in Kotlin Community

Окей, значит это не я дурак, так и сделаю.

источник

14:16пожаловаться #12

V

Vladimir in Kotlin Community

может кто-то сталкивался с проблемой переопределения ленивой инициализации переменных?

пример:

class C(val s:String)

abstract class A {
    open val c:C by

lazy(LazyThreadSafetyMode.NONE) { C("bla") }

}

class B: A() {
    override val c: C by

lazy(LazyThreadSafetyMode.NONE) { C("blabla") }
}

проблема: класс B через раз берет инициализатор для переменной с из родительского класса. К слову у самого не получалось это воспроизвести, но есть отчеты от пользователей, которые говорят о такой проблеме

источник

14:23пожаловаться #13

CL

Constantine Linnick in Kotlin Community

чую что-то с тредами связано

источник

14:24пожаловаться #14

VP

Vladimir Petrakovich in Kotlin Community

Vladimir

может кто-то сталкивался с проблемой переопределения ленивой инициализации переменных?

пример:

class C(val s:String)

abstract class A {
    open val c:C by

lazy(LazyThreadSafetyMode.NONE) { C("bla") }

}

class B: A() {
    override val c: C by

lazy(LazyThreadSafetyMode.NONE) { C("blabla") }
}

проблема: класс B через раз берет инициализатор для переменной с из родительского класса. К слову у самого не получалось это воспроизвести, но есть отчеты от пользователей, которые говорят о такой проблеме

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

источник

14:26пожаловаться #15

V

Vladimir in Kotlin Community

Vladimir Petrakovich

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

здесь можно еще конечно на android погрешить, потому, что в моем случае в C передается идентификатор view. В родительском классе передается View.NO_ID, а в дочернем R.id.view_id. Но в R айдишники заранее проинициилазарованы, поэтому грешу lazy

источник

14:50пожаловаться #16

BP

Bogdan Panchenko in Kotlin Community

Vladimir

здесь можно еще конечно на android погрешить, потому, что в моем случае в C передается идентификатор view. В родительском классе передается View.NO_ID, а в дочернем R.id.view_id. Но в R айдишники заранее проинициилазарованы, поэтому грешу lazy

Не стоит, если вам не удалось воспроизвести.

источник

14:58пожаловаться #17

V

Vladimir in Kotlin Community

Bogdan Panchenko

Не стоит, если вам не удалось воспроизвести.

ну да, вроде логично)

источник

14:58пожаловаться #18

BP

Bogdan Panchenko in Kotlin Community

Vladimir

может кто-то сталкивался с проблемой переопределения ленивой инициализации переменных?

пример:

class C(val s:String)

abstract class A {
    open val c:C by

lazy(LazyThreadSafetyMode.NONE) { C("bla") }

}

class B: A() {
    override val c: C by

lazy(LazyThreadSafetyMode.NONE) { C("blabla") }
}

проблема: класс B через раз берет инициализатор для переменной с из родительского класса. К слову у самого не получалось это воспроизвести, но есть отчеты от пользователей, которые говорят о такой проблеме

А Thread Safety зачем отключаете ? Вот возможно в нем и будет артефакт

источник

14:59пожаловаться #19

V

Vladimir in Kotlin Community

Bogdan Panchenko

А Thread Safety зачем отключаете ? Вот возможно в нем и будет артефакт

за тем, чтобы инитилось быстррее, потому что только из main дергаю переменную, зачем мне Thread save?

источник

15:00пожаловаться #20