По общему мнению, это функция, которая выглядит как ошибка.
Полезное обсуждение на форуме Swift. Также здесь . Основные моменты (отредактированы для ясности) включают:
В первую очередь веские причины не делать этого:
Вы не должны мутировать во время View инициализации, поскольку это будет в вызове body родительского представления
@State переменные в SwiftUI не должны инициализироваться из данных, которые вы передаете через инициализатор; поскольку модель поддерживается за пределами представления, нет никакой гарантии, что это значение действительно будет использоваться.
Не пытайтесь переопределить начальное значение @State в течение init . Он будет работать только один раз во время создания самого первого представления (важно: не инициализация значения) и только в том случае, если это представление в дереве представлений будет воссоздано / заменено другим представлением того же типа, но с другим внутренним идентификатором.
Позиция «это неправильная функция» (близкая к моей):
- Это происходит из-за искусственного ограничения в реализации компилятором оболочек свойств. Обходной путь - инициализировать резервное хранилище напрямую через
_value
Объяснение того, как и почему:
Значение в @State всегда будет инициализировано со значением, которое вы передаете в init, это простой Swift. Однако перед следующим вызовом body SwiftUI вызовет метод обновления и повторно вставит в него значение, если существовало предыдущее значение, которое заменит ваше значение из инициализации.
Это НЕ ошибка! : man_facepalming: Работает, как ожидалось / рекламировалось. ... @State обертка свойств добавляет один возможный способ изменения представления, который также должен быть частным для представления, а не инициализирован из родительского элемента, et c.
Это ошибка пилота (вероятно, правда):
- Здесь нет НИКАКИХ проблем, за исключением того, что люди неправильно понимают, для чего строится State.