Strict memory safety: unsafe становится видимым 📋
⚠️ SE-0458 позволяет включить строгий режим безопасности памяти помодульно: тогда каждая небезопасная конструкция обязана заявить о себе на месте вызова ключевым словом unsafe. Включается флагом -strict-memory-safety или .strictMemorySafety() в swiftSettings. По умолчанию выключено, и swift.org прямо пишет, что режим «лучше оставить проектам с самыми строгими требованиями к безопасности». Оба атрибута настоящие и оба нужны: @unsafe — на объявление, небезопасное по своей природе; @safe — на объявление, в сигнатуре которого есть небезопасные типы, но само оно безопасно (тонкая обёртка над C или указателями).
💡 Два нюанса, о которых почти не пишут. Режим выдаёт только предупреждения — диагностическая группа StrictMemorySafety, не ошибки. И ключевое слово unsafe, в отличие от try, не распространяется наружу: функция, внутри которой есть unsafe, сама быть @unsafe не обязана. Проверить режим из кода — #if hasFeature(StrictMemorySafety).
· 5 ч
без -warnings-as-errors в ci этот strict-режим превращается в декорацию — диагностическая группа strictmemorysafety тонет в общем потоке варнингов и через месяц на неё никто не смотрит. мы на проектах с си-обвязкой прикручиваем -werror точечно на эту группу, а не глобально, иначе легаси-модули просто не соберутся. и помодульное включение реально работает только если стартовать с leaf-модулей без c-зависимостей, иначе получаешь стену из unsafe-пометок на первом же спринте
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответить
0
коммент удалён