SwiftUI 2020. Что изменилось?

[@RomanKerimov]

Расширили поддержку контролов. Теперь практически все контролы UIKit портированы на SwiftUI

Огорчает, что TextEditor не может работать с форматированным текстом.

[@anioutka]

Я думаю, предложат какое-то решение на основе ViewModifier. Механизм мощный достаточно

[@RomanKerimov]

Да тут и NSAttributedString/NSMutableAttributedString выглядит изрядно устаревшим, и как‐то не очень было бы тянуть это в SwiftUI. Так что им и с хранением форматированного текста нужно что‐то придумать.

[@anioutka]

Скорее всего, это будет портирование решения на основе тэгов, как в HTML. Во-первых, они смотрят на Web, во-вторых, очень много готовых народных решений, использующих именно этот принцип. Так что вопрос времени.

[@anon12332]

Переход внутри на структуры позволяет использовать передачу по значению вместо ссылок

Там же копирование будет происходить, причём deep copy?
Разве это не вызовет расходы по памяти?
Разработчики языка swift только ещё планируют moveonly struct, но это, вроде в swift 6?

[@anioutka]

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

Да, согласна. Тут много острых моментов.
Посмотрим, они анонсировали Deep Dive про управление памятью на 26-27 июня.

[@anon12332]

при использовании классов срабатывает ARC, в swift классы — это ссылочные типы данных.
Есть сомнения, что чем больше в программе на swift создаётся переменных классов, тем чаще срабатывает ARC, тем медленнее swift-программа.

[@anioutka]

Тут Apple аргументируют, сравнивая размеры heap из подхода objective-c тогда и Swift сейчас. Больше heap, дольше компиляция. Но как бы тут дело именно в их memory layout, а не использовании ссылок самом по себе. Что происходит внутри:


И как они делают это сейчас:

[@RomanKerimov]

Так структура View в SwiftUI — это в основном метод body, оформленный как вычислимое свойство.

[@anioutka]

Тут основная загадка — как будет все это оперироваться в процессе изменения и пересоздания. Все-таки будет что-то, что будет хранить состояние тех же вычисляемых свойств. + внутри остались объекты от UIKit. Мне еще интересно, как это будет оперировать с UIViewRepresentable. Если они, конечно, от него не отказались.
Пока сессии по перформансу именно в SwiftUI не было, и мне самой интересно, затронуть ли они этот вопрос расширенно. Может быть, в процессе внедрения DSL в Swift 5.3 уже все вообще учтено

[@Florelit]

Насколько знаю, у них там есть оптимизация copyOnWrite для value типов.