Примерно по такой же стратегии действовал (но сильно упрощенно), когда учился в универе и работал, мозг сам рано или поздно перестраивается под нужные требования
Swift Concurrency в Swift 6 со strict mode гарантирует потокобезопасность на уровне компилятора для Sendable, акторов и тп. В случае с @preconcurrency мы фактически доверяем исходному фреймворку. Если CoreBluetooth был потокобезопасным и корректно использовался до Swift 6, то его использование с этим атрибутом не ухудшает ситуацию
У нас в команде были мысли попробовать затянуть этот пакет, но пока ничего не решили. Каналы да – прикольная тема. Но даже сам AsyncStream у нас очень не часто в проекте встречается :)
Спасибо за статью
Примерно по такой же стратегии действовал (но сильно упрощенно), когда учился в универе и работал, мозг сам рано или поздно перестраивается под нужные требования
Я думаю это скорее абстрактный вариант, дело же могло быть и на стройке, где найти дополнительного разнорабочего не трудно и не долго
На самом деле хорошая статья :)
По сути самая проблемная часть находится тут:
Swift Concurrency в Swift 6 со strict mode гарантирует потокобезопасность на уровне компилятора для Sendable, акторов и тп. В случае с
@preconcurrencyмы фактически доверяем исходному фреймворку. Если CoreBluetooth был потокобезопасным и корректно использовался до Swift 6, то его использование с этим атрибутом не ухудшает ситуациюУ нас в команде были мысли попробовать затянуть этот пакет, но пока ничего не решили. Каналы да – прикольная тема. Но даже сам AsyncStream у нас очень не часто в проекте встречается :)