@c: вызывать Swift напрямую из C ‼️
🔌 SE-0495 «C compatible functions and enums» (Swift 6.3) формализует экспериментальный @_cdecl: помечаете глобальную функцию или энум с целочисленным raw-типом, и Swift печатает соответствующее объявление в сгенерированный заголовок для C. Что может пересечь границу: примитивы стандартной библиотеки, Unsafe*Pointer и OpaquePointer, примитивы C, ссылки на @convention(c)-функции, SIMD, @c-энумы и импортированные C-типы. Что не может: структуры Swift, String, массивы, замыкания, экзистенциалы протоколов, не-@objc классы и опциональные не-указательные типы. Методы и вычисляемые свойства вообще вне области действия — только глобальные функции.
⚠️ Две поправки. Первая: @_cdecl этим пропозалом не задепрекейчен — слова «deprecat» в тексте нет ни разу. Вторая, более практичная: замена @_cdecl на @c ломает ABI, потому что @_cdecl эмитит два символа. Существующим адоптерам предлагают либо @objc для сохранения поведения, либо осознанный переход на более строгий @c. Без явного имени экспортируемый символ — это просто базовое имя функции в Swift. И есть @c @implementation: им реализуют функцию, уже объявленную в рукописном C-заголовке, с проверкой совпадения сигнатур.
· 05.08
для тех кто уже юзает @_cdecl в проде — @c @implementation это реально главный вин пропозала, потому что матчинг сигнатур на этапе компиляции убивает целый класс тихих ub на границе ffi. у нас было пару раз когда несовпадение типов ловилось только в краш-репортах, а не в билде, и вот это как раз тот скучный compile-time чек, который экономит нервы
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён