Нет, в этом случае вам не нужен [weak self]. Вот почему:
1️⃣ Задача Task захватывает self stronlgy, но это не Retain Cycle
Поскольку задача Task не сохраняется (это эфемерный асинхронный блок), она завершит и освободит свои ссылки, включая self. 2️⃣ DispatchQueue.main.async не вызывает Retain Cycle Замыкание DispatchQueue.main.async также захватывает self stronlgy, но поскольку оно выполняется асинхронно и завершается немедленно, оно не вызовет Retain Cycle.
А вот ответ Gemini 2.0 Flash Thinking Experimental
Почему [weak self] технически не нужен в вашем фрагменте кода:
Задача Task привязана к жизненному циклу View: задача запускается при появлении View (из-за .task) и отменяется при исчезновении View. Операции связаны с UI: выборка стран и обновление @State — это операции, напрямую связанные с UI . Нет долгоживущей фоновой задачи: это не фоновая задача, предназначенная для выполнения независимо от View в течение длительного периода.
Вкратце:
Для типичного использования модификатора .task SwiftUI для асинхронных операций, связанных с View, таких как выборка данных, [weak self] обычно не требуется для безопасности памяти из-за управления жизненным циклом задач SwiftUI. SwiftUI разработан для безопасной обработки этих случаев.
Однако добавление [weak self] также не нанесет никакого вреда в этом сценарии. Некоторые могут посчитать это немного более защитным кодированием или вопросом личных предпочтений, чтобы быть явным в отношении семантики захвата. Но для общих шаблонов SwiftUI с .task это часто считается излишней многословностью и не идиоматичным.
Поэтому в предоставленном вами коде вам не нужно использовать [weak self]. .task SwiftUI разработан для правильной обработки жизненного цикла без необходимости вручную добавлять weak self, чтобы избежать утечек памяти в этих типичных сценариях.
Современным студентам Стэнфорда читают только async /await.
Что ж Apple, конечно, намудрила с Swift6 strict concurrency, но после этой статьи голова реально просветлеет. Мне она очень помогла - автор великолепный.
Ну, вы загнули насчет того, что статья сгенерирована в ChatGPT. Да, в ней дословно приводятся "рассуждения" ChatGPT, но они скрыты, чтобы не загромождать текст статьи - кто хочет, тот прочитает, а обычным читателям может и не понадобится.
Что касается старого CGD (Central Grand Dispatch), то на работоспособность приложения это, конечно, не влияет, но на читабельность кода влияет очень сильно. одна Pyramid of doom чего стоит, впрочем посмотрите статью Swift async/await. Чем он лучше GCD?. Там все очень подробно написано.
Что касается меня, то я очень люблю CGD и владею им в совершенстве (Многопоточность (concurrency) в Swift 3. GCD и Dispatch Queues), с трудом перешла на async / await, но сейчас вижу его огромные преимущества. Даже на примере этой статьи код с async / await намного лаконичнее и он линейный - не надо думать, что сработает раньше, а что позже.
Что касается Swift 6 strict concurrency, то это борьба с "гонкой данных" на уровне компиляции. Вы когда-нибудь сталкивались с "гонкой данных"? В статье Многопоточность (concurrency) в Swift 3. GCD и Dispatch Queues) приводится такой пример: на UI пользователь задаёт url и ждет изображение, оно долго не приходит и пользователь меняет url, для которого изображение тут же приходит, но спустя некоторое время приходит предыдущее изображение, уже не соответствующее заданному пользователем url и "забивает" ваще правильное изображение. В случае CGD нужно обнаружить "гонкой данных" и бороться с ним на уровне кода.
Кстати, никакой сложности кода в геометрической прогрессии нет : ставишь @MainActor перед class ViewModel и помечаешь fetch функции как nonisolated. Смотри пост Многопоточность по шагам: Сетевой запрос.
Но использование Swift 6 strict concurrency конкретно в этом тестовом приложении была в том, чтобы "дожать" ChatGPT, понять границу, где он "сломается". К сожалению, а может быть к счастью, ChatGPT, а также DeepSeek, на сложных вещах "не ломаются", они "ломаются" на очень простых вещах, например, на "человеческих" ошибках проектирования API Всемирного банка.
Первоначально был запрос общего характера: к моему любимому ИИ - Claude 3.5 Sonnet "Создай iOS приложение, которое показывает страны Мира по категориям. Используй информацию Всемирного Банка". Просто хотелось понять, сможет ли он найти сайты, понять, как устроен JSON, создать Модель Данных, декодировать её и создать хоть какой-то UI для сгруппированных стран.
И тут же получаю iOS приложение с кодом, который НЕ РАБОТАЕТ. Вроде сайт Всемирного Банка ИИ нашел, Модель данных создал, UI тоже нормальный, а Decode не может выполнить. Да, JSON - нестандартный, но не такой уж и сложный, но как я "не упрашивала" Claude 3.5 Sonnet - не хочет, не натренирован, не обучен, не знаю. Пришлось этот частный вопрос декодирования конкретных JSON данных решать c ChatGPT, в результате получаю правильные 3 строчки кода, которые и предлагаю Claude 3.5 Sonnet, с которым продолжаю работать, так как код для UI у него всегда замечательный.
И тут появляется DeepSeek, а затем и ChatGPT 4.o3-mini.
Даю и тому, и другому ту же общую задачу - с первого раза великолепный результат, вообще никаких проблем с Decode.
Хочу добавить дополнительную информацию о населении и ВВП страны ( как оказалось выборки с других endpoints) - ChatGPT 4.o3-mini практически сразу великолепный результат, DeepSeek чуть запутался, но не смертельно, чуть "пнула" - всё понял и исправился.
Аппетит приходит во время еды,
Прошу перейти к новому и очень сложному Swift 6 strict concurrency - оба справляются.
Хочу страну на карте Мира - все работает, но оба пытаются подсунуть мне старый API. Прошу новый - оба "слушаются" и выдают правильный результат, но по-разному.
Так что - ДА, понадобилось 8 Prompts, чтобы получить окончательное приложение.
Если получили не работающий результат - не отступайте, дело может быть в одной букве или паре строк кода.
8 летние девочки не задают prompts c concurrency. Как бы вам это не представлялось, задания (prompts) задаёт квалифицированный программист и ответы оценивает он же. Так что ВЫ ведете ИИ и туда, куда ВАМ нужно. Так вот ChatGPT o3-mini очень хорошо отвечает на правильно поставленные вопросы, как и DeepSeek, но он чаще ошибается и его приходится "подталкивать" в нужном направлении, он неплохо "слушается" и это сокращает ВАШЕ время написания iOS приложения. И в этом их прелесть.
Нет никаких иллюзий, что за вас кто-то напишет приложение.
При написание кода, особенно на таких прогрессирующих языках программирования, как Swift, есть очень большая вероятность, что вам предоставят решение с устаревшей версией. И так оно и было с Claude 3.5 sonnet и ChatGPT 4o1, не говоря уже о Gemini 1.5, который выдаёт позавчерашнюю версию языка.
Но ситуация с ChatGPT 4o3-mini и DeepSeek существенно изменилась в лучшую сторону.
Попробуйте сами повторить все действия с этим приложением. Cursor AI имеет бесплатный тариф и доступен в России, что не скажешь про ChatGPT и Claude 3.5 Sonnet
Возможно. Но у меня отрицательный опыт с ChatGPT 4.o-mini на русском - качество Swift SwiftUI кода намного ниже, хотя в целом код неплохой. Поэтому предпочитаю английский. В чистом Claude 3.5 Sonnet без Cursor - та же проблема. Я объясняю это базой обучения.
Извините, в качестве ссылки на Monte Carlo дала ссылку на medium.com, который в России не открывается. Исправлено. Больше не нашла ссылок, которые не открываются. Если не составит труда, подскажите, какие не открываются в России - заменю.
А "затасканная" задача была взята намеренно, чтобы не париться с контекстом. Уж не знаю, что где взял ChatGPT, но задачу понимает абсолютно точно. Я пробовала еще физические задачи : типа скользит шарик по сфере и в какой-то точке отрывается и начинает падать свободно - прекрасно рисует траекторию.
Абсолютно не лень. Азарт. Попробуйте, взять что-нибудь знакомое и проделать то же самое с известной вам задачей. Вам понравится. Под конец уже совсем наглеешь, а ChatGpt все равно выдает очень приличный код.
Кстати, что странно, я не заметила, чтобы chatGPT обворовывает GitHub. Уж поверьте, я все просмотрела. Код оригинальный, особенно в части concurrency. Что приятно удивило.
Упомянутая вами статья касается очень небольшого вопроса, связанного с различной трактовкой Optional в Core Data и в Swift. Это противоречие очень просто убирается путем добавления небольшого кода в расширении extension классов, соответствующих объектам Core Data. Моя статья посвящена возможностям, предоставленным Apple для Core Data в новом фреймворке SwiftUI и так и называется "Core Data в современном интерьере SwiftUI". Упомянутый вами вопрос составляет менее 1% от содержания моей статьи. Мне искренне жаль, что вы не поняли тех беспрецедентных возможностей, которые имеются в настоящее время у Core Data при работе в SwiftUI.
Да, это фантастический протокол Transferable. Тоже работаю над статьей о Transferable. для своего блога. Но чтобы это оценить, надо понимать, что было до появления этого протокола, то есть до iOS 16+.
За операции Drag & Drop (перетаскивание и "сброс") отвечал класс class NSItemProvider. Именно этот класс делает очень сложные вещи, связанные с передачей данных между процессами. Он также решает проблемы с безопасностью и определенно там есть многопоточность, потому что мы не хотим блокировать UI двух приложений в случае передачи между ними больших по объему изображений.
К сожалению, класс NSItemProvider — это до-Swift класс, и мы должны использовать “as” как “мостик” между такими Swift ТИПами как String, и такими ТИПами старого NS Мира, как NSString, это Objective-C вещи, и “as” является “мостом” в этот старый мир. До появления протокола Transferable технология Drag & Drop (перетаскивание и сброс) была одним из таких мест соприкосновения "старого" и нового Миров.
Почти параллельно с вашей статьей появились две статьи об опыте использования протокол Transferable :
Единственное, до чего не "дотягивает" протокол Transferable и соответствующий ему View модификатор dropDestination(for:action:isTargeted:), это возможность указания нескольких UTType.
Класс Operation имеет метод cancel(), однако использование этого метода только устанавливает свойство isCancelled в true, а что семантически означает «удаление» операции можно определить только при создании subclass Operation. Например, в случае загрузки данных из сети можно определить cancel() как отключение операции от сетевого взаимодействия.
Посмотрите мою другую статью "Concurrency в Swift 3 и 4. Operation и OperationQueue" в Habr, специально посвященную Operation.
Да, странные ссылки, вторая ссылка вообще 2020 года. Не пользовалась Perplexity, хотя его вроде хвалят.
Кстати внутри ChatGPT есть Swift Copilot -он очень хорош, все четко и по делу.
Спросила ChatGPT ваш вопрос:
Нам необходим [weak self] в коде:
Вот что он ответил:
Нет, в этом случае вам не нужен [weak self]. Вот почему:
1️⃣ Задача Task захватывает self stronlgy, но это не Retain Cycle
Поскольку задача Task не сохраняется (это эфемерный асинхронный блок), она завершит и освободит свои ссылки, включая self.
2️⃣ DispatchQueue.main.async не вызывает Retain Cycle
Замыкание DispatchQueue.main.async также захватывает self stronlgy, но поскольку оно выполняется асинхронно и завершается немедленно, оно не вызовет Retain Cycle.
А вот ответ Gemini 2.0 Flash Thinking Experimental
Почему [weak self] технически не нужен в вашем фрагменте кода:
Задача Task привязана к жизненному циклу View: задача запускается при появлении View (из-за .task) и отменяется при исчезновении View.
Операции связаны с UI: выборка стран и обновление @State — это операции, напрямую связанные с UI .
Нет долгоживущей фоновой задачи: это не фоновая задача, предназначенная для выполнения независимо от View в течение длительного периода.
Вкратце:
Для типичного использования модификатора .task SwiftUI для асинхронных операций, связанных с View, таких как выборка данных, [weak self] обычно не требуется для безопасности памяти из-за управления жизненным циклом задач SwiftUI. SwiftUI разработан для безопасной обработки этих случаев.
Однако добавление [weak self] также не нанесет никакого вреда в этом сценарии. Некоторые могут посчитать это немного более защитным кодированием или вопросом личных предпочтений, чтобы быть явным в отношении семантики захвата. Но для общих шаблонов SwiftUI с .task это часто считается излишней многословностью и не идиоматичным.
Поэтому в предоставленном вами коде вам не нужно использовать [weak self]. .task SwiftUI разработан для правильной обработки жизненного цикла без необходимости вручную добавлять weak self, чтобы избежать утечек памяти в этих типичных сценариях.
Современным студентам Стэнфорда читают только async /await.
Лекция 14. Многопоточность. Обработка ошибок.
Насчет Swift 6 все таки очень очень -очень советую статью Concurrency Step-by-Step: A Network Request или её русскоязычный перевод пост Многопоточность по шагам: Сетевой запрос.
Что ж Apple, конечно, намудрила с Swift6 strict concurrency, но после этой статьи голова реально просветлеет. Мне она очень помогла - автор великолепный.
Ну, вы загнули насчет того, что статья сгенерирована в ChatGPT. Да, в ней дословно приводятся "рассуждения" ChatGPT, но они скрыты, чтобы не загромождать текст статьи - кто хочет, тот прочитает, а обычным читателям может и не понадобится.
Что касается старого CGD (Central Grand Dispatch), то на работоспособность приложения это, конечно, не влияет, но на читабельность кода влияет очень сильно. одна Pyramid of doom чего стоит, впрочем посмотрите статью Swift async/await. Чем он лучше GCD?. Там все очень подробно написано.
Что касается меня, то я очень люблю CGD и владею им в совершенстве (Многопоточность (concurrency) в Swift 3. GCD и Dispatch Queues), с трудом перешла на async / await, но сейчас вижу его огромные преимущества. Даже на примере этой статьи код с async / await намного лаконичнее и он линейный - не надо думать, что сработает раньше, а что позже.
Что касается Swift 6 strict concurrency, то это борьба с "гонкой данных" на уровне компиляции. Вы когда-нибудь сталкивались с "гонкой данных"? В статье Многопоточность (concurrency) в Swift 3. GCD и Dispatch Queues) приводится такой пример: на UI пользователь задаёт url и ждет изображение, оно долго не приходит и пользователь меняет url, для которого изображение тут же приходит, но спустя некоторое время приходит предыдущее изображение, уже не соответствующее заданному пользователем url и "забивает" ваще правильное изображение. В случае CGD нужно обнаружить "гонкой данных" и бороться с ним на уровне кода.
Кстати, никакой сложности кода в геометрической прогрессии нет : ставишь @MainActor перед class ViewModel и помечаешь fetch функции как nonisolated. Смотри пост Многопоточность по шагам: Сетевой запрос.
Но использование Swift 6 strict concurrency конкретно в этом тестовом приложении была в том, чтобы "дожать" ChatGPT, понять границу, где он "сломается". К сожалению, а может быть к счастью, ChatGPT, а также DeepSeek, на сложных вещах "не ломаются", они "ломаются" на очень простых вещах, например, на "человеческих" ошибках проектирования API Всемирного банка.
Первоначально был запрос общего характера: к моему любимому ИИ - Claude 3.5 Sonnet "Создай iOS приложение, которое показывает страны Мира по категориям. Используй информацию Всемирного Банка". Просто хотелось понять, сможет ли он найти сайты, понять, как устроен JSON, создать Модель Данных, декодировать её и создать хоть какой-то UI для сгруппированных стран.
И тут же получаю iOS приложение с кодом, который НЕ РАБОТАЕТ. Вроде сайт Всемирного Банка ИИ нашел, Модель данных создал, UI тоже нормальный, а Decode не может выполнить. Да, JSON - нестандартный, но не такой уж и сложный, но как я "не упрашивала" Claude 3.5 Sonnet - не хочет, не натренирован, не обучен, не знаю. Пришлось этот частный вопрос декодирования конкретных JSON данных решать c ChatGPT, в результате получаю правильные 3 строчки кода, которые и предлагаю Claude 3.5 Sonnet, с которым продолжаю работать, так как код для UI у него всегда замечательный.
И тут появляется DeepSeek, а затем и ChatGPT 4.o3-mini.
Даю и тому, и другому ту же общую задачу - с первого раза великолепный результат, вообще никаких проблем с Decode.
Хочу добавить дополнительную информацию о населении и ВВП страны ( как оказалось выборки с других endpoints) - ChatGPT 4.o3-mini практически сразу великолепный результат, DeepSeek чуть запутался, но не смертельно, чуть "пнула" - всё понял и исправился.
Аппетит приходит во время еды,
Прошу перейти к новому и очень сложному Swift 6 strict concurrency - оба справляются.
Хочу страну на карте Мира - все работает, но оба пытаются подсунуть мне старый API. Прошу новый - оба "слушаются" и выдают правильный результат, но по-разному.
Так что - ДА, понадобилось 8 Prompts, чтобы получить окончательное приложение.
Если получили не работающий результат - не отступайте, дело может быть в одной букве или паре строк кода.
8 летние девочки не задают prompts c concurrency. Как бы вам это не представлялось, задания (prompts) задаёт квалифицированный программист и ответы оценивает он же. Так что ВЫ ведете ИИ и туда, куда ВАМ нужно. Так вот ChatGPT o3-mini очень хорошо отвечает на правильно поставленные вопросы, как и DeepSeek, но он чаще ошибается и его приходится "подталкивать" в нужном направлении, он неплохо "слушается" и это сокращает ВАШЕ время написания iOS приложения. И в этом их прелесть.
Нет никаких иллюзий, что за вас кто-то напишет приложение.
При написание кода, особенно на таких прогрессирующих языках программирования, как Swift, есть очень большая вероятность, что вам предоставят решение с устаревшей версией. И так оно и было с Claude 3.5 sonnet и ChatGPT 4o1, не говоря уже о Gemini 1.5, который выдаёт позавчерашнюю версию языка.
Но ситуация с ChatGPT 4o3-mini и DeepSeek существенно изменилась в лучшую сторону.
Попробуйте сами повторить все действия с этим приложением. Cursor AI имеет бесплатный тариф и доступен в России, что не скажешь про ChatGPT и Claude 3.5 Sonnet
В течение пары часов приложение было готово. Я просто повторно делала скриншоты для статьи,
Возможно. Но у меня отрицательный опыт с ChatGPT 4.o-mini на русском - качество Swift SwiftUI кода намного ниже, хотя в целом код неплохой. Поэтому предпочитаю английский. В чистом Claude 3.5 Sonnet без Cursor - та же проблема. Я объясняю это базой обучения.
Извините, в качестве ссылки на Monte Carlo дала ссылку на medium.com, который в России не открывается. Исправлено. Больше не нашла ссылок, которые не открываются. Если не составит труда, подскажите, какие не открываются в России - заменю.
А "затасканная" задача была взята намеренно, чтобы не париться с контекстом. Уж не знаю, что где взял ChatGPT, но задачу понимает абсолютно точно. Я пробовала еще физические задачи : типа скользит шарик по сфере и в какой-то точке отрывается и начинает падать свободно - прекрасно рисует траекторию.
Абсолютно не лень. Азарт. Попробуйте, взять что-нибудь знакомое и проделать то же самое с известной вам задачей. Вам понравится. Под конец уже совсем наглеешь, а ChatGpt все равно выдает очень приличный код.
Кстати, что странно, я не заметила, чтобы chatGPT обворовывает GitHub. Уж поверьте, я все просмотрела. Код оригинальный, особенно в части concurrency. Что приятно удивило.
Упомянутая вами статья касается очень небольшого вопроса, связанного с различной трактовкой Optional в Core Data и в Swift. Это противоречие очень просто убирается путем добавления небольшого кода в расширении extension классов, соответствующих объектам Core Data. Моя статья посвящена возможностям, предоставленным Apple для Core Data в новом фреймворке SwiftUI и так и называется "Core Data в современном интерьере SwiftUI". Упомянутый вами вопрос составляет менее 1% от содержания моей статьи. Мне искренне жаль, что вы не поняли тех беспрецедентных возможностей, которые имеются в настоящее время у Core Data при работе в SwiftUI.
Это обычная практика. Посмотрите, например, эту статью SwiftUI views versus modifiers.
По-моему как раз наоборот: сразу видны все Swift ключевые слова и легче соориентироваться.
Исправлено. Repository был private
Да, это фантастический протокол Transferable. Тоже работаю над статьей о Transferable. для своего блога. Но чтобы это оценить, надо понимать, что было до появления этого протокола, то есть до iOS 16+.
За операции Drag & Drop (перетаскивание и "сброс") отвечал класс class NSItemProvider. Именно этот класс делает очень сложные вещи, связанные с передачей данных между процессами. Он также решает проблемы с безопасностью и определенно там есть многопоточность, потому что мы не хотим блокировать UI двух приложений в случае передачи между ними больших по объему изображений.
К сожалению, класс NSItemProvider — это до-Swift класс, и мы должны использовать “as” как “мостик” между такими Swift ТИПами как String, и такими ТИПами старого NS Мира, как NSString, это Objective-C вещи, и “as” является “мостом” в этот старый мир. До появления протокола Transferable технология Drag & Drop (перетаскивание и сброс) была одним из таких мест соприкосновения "старого" и нового Миров.
Почти параллельно с вашей статьей появились две статьи об опыте использования протокол Transferable :
First Experience With Transferable Implementing Drag And Drop In SwiftUI
Transferable Protocol in SwiftUI – Transferring Alternative Content With ProxyRepresentation
Единственное, до чего не "дотягивает" протокол Transferable и соответствующий ему View модификатор dropDestination(for:action:isTargeted:), это возможность указания нескольких UTType.
Раньше, до iOS 16+:
Теперь, начиная с iOS 16+:
Но выход есть:
Класс
Operationимеет методcancel(), однако использование этого метода только устанавливает свойствоisCancelledвtrue, а что семантически означает «удаление» операции можно определить только при созданииsubclass Operation. Например, в случае загрузки данных из сети можно определитьcancel()как отключение операции от сетевого взаимодействия.Посмотрите мою другую статью "Concurrency в Swift 3 и 4. Operation и OperationQueue" в Habr, специально посвященную
Operation.https://habr.com/ru/post/335756/
По-моему там есть пример.
По сути, assign(to:) - это прямая передача публикуемого значения другому "издателю" Publisher $currentWeather и никакой reference cycle не возникает.