C# 16, который Microsoft планирует выпустить в конце 2027 года вместе с .NET 12 LTS, должен заметно изменить правила игры для низкоуровневого кода. Компания не собирается превращать язык в Rust, но хочет сделать безопасность C# более явной: все участки, где разработчик реально лезет в неуправляемую память, будут подсвечены жёстче, а значит, их станет проще ревьюить и сложнее пропустить.
О планах команды .NET сообщает The Register со ссылкой на большой пост продакт-менеджера .NET Ричарда Ландера. По его словам, Microsoft видит будущее, в котором C# будут выбирать не только за удобство managed-мира, но и за дисциплину в части type safety и memory safety. Звучит амбициозно, хотя речь не о переписывании языка с нуля и не об отказе от сборщика мусора, а о пересборке старого механизма unsafe, который тянется за C# с самой первой версии.
До сих пор слово unsafe в C# работало довольно грубо. Если сильно упростить, оно открывало дверь в режим «пишем кусок C внутри программы на C#»: можно использовать указатели, арифметику указателей и код, который .NET runtime уже не страхует своими обычными гарантиями. Для большинства корпоративных разработчиков это экзотика: CRUD, веб-сервисы, внутренние платформы и типичные бизнес-приложения живут вообще без unsafe. Но как только дело доходит до interop с ОС, memory-mapped device, низкоуровневых библиотек или куска кода, где важна каждая лишняя инструкция, unsafe возвращается в повестку.
Теперь Microsoft хочет сделать этот режим не менее опасным, а более заметным. Ключевая идея в том, что в новой модели пометка метода как unsafe будет означать не просто «внутри можно опасное», а ещё и «вызывающий код должен явно принять этот риск». Иными словами, unsafe начнёт распространяться вверх по стеку вызовов. Если метод небезопасен, его вызов уже нельзя будет тихо завернуть в с виду безопасный API и сделать вид, что всё под контролем. Для платформенных команд и авторов библиотек это важный сдвиг: контракт станет честнее, а граница между безопасным и небезопасным кодом перестанет быть декоративной.
Есть и более точечные изменения. Microsoft собирается запретить помечать как unsafe целые типы: область действия сдвигается вниз, к конкретным методам, свойствам и полям. Это выглядит как попытка убрать ленивую практику «пометим весь класс, а там разберёмся». Ещё один важный штрих: сами типы указателей и часть операций с ними больше не будут автоматически считаться unsafe. Небезопасным останется именно разыменование указателя, то есть реальный доступ к unmanaged memory. Логика понятна: проблема не в том, что указатель существует, а в том, что через него можно читать и писать куда не надо.
Вокруг дизайна уже есть нормальная инженерная дискуссия. Некоторые участники обсуждения спрашивают, почему команда хочет подавлять распространение unsafe через отсутствие пометки, а не через отдельный модификатор вроде safe. Ландер прямо сказал, что сам продвигал именно такой вариант. Пока, впрочем, предложение движется в другом направлении. Для языка это характерная история: синтаксис и модель безопасности приходится балансировать не только между строгостью и удобством, но и между совместимостью с накопленным кодом за два десятка лет.
Именно обратная совместимость здесь, похоже, и определяет темп реформы. Новая модель появится не раньше C# 16, то есть через две версии языка. Если Microsoft сохранит обычный годовой цикл .NET, релиз придётся на конец 2027 года и выйдет вместе с .NET 12, который должен стать LTS-релизом. При этом ранний preview обещают уже в C# 15 и .NET 11. Важная деталь: переход будет добровольным. Для C# 16 изменения сделают opt-in, поэтому существующие проекты смогут продолжить жить по правилам, знакомым ещё со времён C# 1.0. А вот библиотеки самого .NET runtime, по словам Ландера, в новую модель войдут.
Для экосистемы это даже важнее, чем для отдельных приложений. Если базовые библиотеки платформы начнут маркировать небезопасные участки строже, новый стандарт быстро станет не теорией из proposal, а рабочей нормой. Microsoft вдобавок обсуждает бейджи в NuGet, которые будут показывать, перешёл ли пакет на новую модель. Идея звучит почти по-менеджерски, но польза у неё сугубо практическая: при выборе зависимости команда сможет быстрее понять, насколько авторы пакета вообще думали про безопасность C#, аудит API и прозрачность unsafe-границ.
Реакция разработчиков, судя по публикации, пока скорее позитивная. Один из комментаторов, который работает и с C#, и с Rust, прямо сказал, что его устраивает движение C# в сторону managed-версии Rust. Это, конечно, не означает, что язык внезапно получит borrow checker и всю философию ownership. Но сам вектор понятен: индустрия давно устала от багов, которые возникают не из-за бизнес-логики, а из-за того, что кто-то неаккуратно обошёл защитные механизмы платформы. Microsoft это тоже видит. Не случайно компания параллельно говорит о сокращении зависимости от C и C++ в собственных кодовых базах, а Python- и JavaScript-экосистемы всё чаще оглядываются на Rust, когда разговор заходит о надёжности системного слоя.
Для русскоязычной аудитории эффект будет неравномерным. Большая часть команд, пишущих бэкенды, внутренние сервисы, SaaS и корпоративные системы на .NET, может вообще не заметить нововведение в ежедневной работе. Но для тех, кто делает платформенные компоненты, high-performance библиотеки, интеграцию с нативными SDK, драйверами, специализированным железом или просто поддерживает старый interop-код, новость существенная. Ревью станут проще, границы риска виднее, а разговоры в стиле «тут чуть-чуть unsafe, но наружу ничего не торчит» будет сложнее продавить на доверии. И это, пожалуй, самая практичная форма прогресса: не магия, а меньше слепых зон там, где ошибки обходятся дорого.
Главный вопрос теперь не в том, нужен ли C# этот разворот, а насколько быстро экосистема согласится считать новый режим нормой, а не факультативом. Если runtime-библиотеки и NuGet-пакеты действительно начнут показывать unsafe как предупреждающую маркировку, через несколько релизов спор уже будет не о синтаксисе, а о том, можно ли выпускать серьёзную библиотеку без внятно описанного контракта на небезопасный код. Для безопасности C# это, возможно, важнее любых громких сравнений с Rust.