Extension Members: новый уровень проектирования .NET API или новый уровень сложности?

Extension methods появились в C# много лет назад и стали привычным способом расширять существующие типы без наследования, изменения исходного кода и перекомпиляции библиотек. С выходом .NET 10 и C# 14 эта модель получила развитие в виде Extension Members: теперь расширениями могут быть не только методы, но и свойства, статические члены и операторы.

На первый взгляд, это делает API естественнее: внешний API начинает выглядеть как API самого типа. Можно строить member-like API для доменных примитивов, fluent API и локальных DSL. Но вместе с выразительностью появляется новый слой сложности: компилятор ищет Extension Members в текущем контексте, а результат вызова может зависеть от пространств имен, using/global using, подключенных пакетов и правил разрешения перегрузок.

В докладе разберем, как устроены Extension Members: что пишет разработчик, как компилятор находит подходящие расширения, что попадает в метаданные и что видно через Reflection.

На сквозном примере посмотрим, где Extension Members помогают строить выразительный API, а где удобный синтаксис начинает скрывать важную бизнес-логику. Отдельно обсудим практические риски: неоднозначность вызовов, изменение выбора перегрузки после обновления пакета, влияние using/global using, проблемы семантической совместимости и риски, связанные с перегрузкой операторов через Extension Members.