unsafe место на блоке extern, а не в точке вызова

Carbon целится в противоположный конец. План в том, чтобы код на Carbon напрямую импортировал заголовки C++ без написанных вручную внешних объявлений, так что неверную сигнатуру просто негде набрать. Выдержит ли это история с безопасностью, пока открытый вопрос. Проект сам называет себя экспериментальным, и дизайн безопасности памяти не закончен, поэтому всё сказанное сегодня о корректности взаимодействия Carbon с C++ это намерение, а не поведение.

Сигнатура это половина дела. Вторая половина это раскрутка стека. Паника, пытающаяся выйти из Rust-функции extern "C", теперь прерывает процесс, а исключение C++, переходящее в Rust, определено только через ABI "C-unwind". Значит, объявление должно ещё и говорить, может ли через него что-то раскручиваться. Какой уже созданный объект владеет дескриптором в этот момент? При аварийном завершении ни один деструктор не выполнится.

У этого есть почти близнец в проверке Sendable в Swift. Заголовки C ничего не говорят о том, какой поток что может трогать, поэтому обёртку над C-дескриптором обычно помечают @unchecked Sendable, и компилятор верит автору на слово, почти как с safe fn во внешнем блоке. Такие пометки лучше держать редкими и легко находимыми через grep, с комментарием о том, какая блокировка или очередь делает это правдой. А @preconcurrency import тихо ослабляет диагностику Sendable для модуля, что нормально во время миграции и легко забывается потом.

Не совсем одно и то же. @unchecked Sendable ручается за тип везде, куда он попадёт, а safe fn ручается за предусловия одной внешней функции. И то и другое должно легко находиться через grep, и Rust хотя бы заставляет написать слово unsafe на блоке, где лежит это поручительство, так что один поиск находит все такие утверждения.