здесь путаница-то?
А как это меняет семантику кода?
> if-ы компайлер переписывает на when-ы потому что зачем усложнять парсер ?
Парсер тут ни при чём только -- он-то как раз обе конструкции знает.
Никак, как и то что я хочу иметь возможность инициализировать поле у которого будет backing field.
Дык чтобы это переписать надо сначала распарсить :))
Так вы два поля хотите, вам уже выше объяснили. И кип не об этом.
Где я говорил про два поля?
Вам надо а) где-то хранить мутабельный флоу, б) где-то хранить полученный на его основании ридонли флоу.
Да, но в этом кипе это просто спрятано под ковёр нет разве? Или компилятор будет делать смарткаст когда я обращаюсь к из приватной области видимости?
нет, там одно поле, в этом и смысл, вот почему гетер всегда выдает новый объект
https://github.com/Kotlin/KEEP/blob/c27a5b2d858d5e688d165bc5b7d4c9f7557b65c4/proposals/explicit-backing-fields.md#smart-type-narrowing Вот же ответ
ну "парсить" я не коректно назвал. короче проще компилятор писать. Вы думаете просто так решили в компилятор все ифы переделать ? Типо нечем занятся компиляторщикам ?
Понятно... ну тогда это и не эквивалент для двух полей, там я могу обеспечить всегда один объект для asStateFlow()
Не эквивалент. Я не знаю, с чего вы взяли, что эквивалент :)
нет но вы можете просто сделать тип гетера не мутабельным, как в примере с листом
Да я понимаю зачем это сделано.
Ну... как бы и ни с чего :) просто это так естественно вписывалось бы (не принимая во внимание конечно что понадобилось бы ещё одно скрытое поле для хранения иммутабельного враппера)
Я не хочу "просто сделать тип немутабельным" :) потому что ссылка на объект не поменяется и значит кто угодно может его кастануть обратно
та же проблема с колекциями
Ну да, просто у коллекций даже нет метода для создания немутабельного враппера, поэтому пример с ними не получился бы
есть в джаве если что - они бросают exception
А в "тюрьме сейчас макароны"... :) много чего где есть
Обсуждают сегодня