VD>>Ну, и твои подозрения, что расширения синтаксиса это что-то сложное, страшное и опасное ничем не отличаются от подозрений оп поводу того, что "var" сделает код программ нечитабельным.
S>Чтоб не спорить впустую — можешь привести реальный полезный пример расширения синтаксиса?
S>Потому что для AOP я с ходу десяток примеров приведу, для расширения синтаксиса — только мелочёвка типа счётчика в foreach или foreach ... else. Ну несерьёзно это

1) readlock(ReaderWriterLock/Slim){} / writelock(ReaderWriterLock/Slim){}, их же для локов на async/await (реврайтер там уровня using)

2) .FirstOrDefault, .Distinct, и прочие — думаю имей C# расширения, появились бы в nuget'е через неделю после выхода linq, включая insert, update, delete

3) Razor — он же по сути своей расширение синтаксиса C# (если на него посмотреть как на C# в котором можно фигачить текст, а не как текст в котором можно фигачить C#), туда же весь .xaml — оформить как расширение синтаксиса в духе Razor, ибо xml не ах

4) interlocked-переменные (ты ей ++, а под капотом вызывается Interlocked.Increment, ты ей += а там .Add, и т.п.)

5) генераторы не как в C#, а как в EcmaScript 6, где можно var a = yield return b; — тогда связанные между собой конечные автоматы становятся проще

6) def или let для иммутабельных переменных, в противовес var который мутабельный

7) var d = new Dictionary<string name, DateTime dateOfBirth>() — и чтоб в этом Dictionary с этого момента никаких TKey и TValue, а мои name и dateOfBirth, и чтоб Intellisense понимал

8) Возможность объявлять произвольные операторы (по идее тут можно и без макросов расширения синтаксиса)

9) Встраивание кода на другом языке, например asm { и погнали на IL }

10) mixin-ы (тут не уверен, может можно выкрутиться на имеющемся синтаксисе)

11) Встроенный парсинг простых регулярок, например regex var {(?<a:int>\d+)\s*-\s*(?<b:decimal, auto>)\s*-\s*(?<c:double,auto>)} = str; — с раскраской и автокомплитом, произвольной закрывающей скобкой (определяется по открывающей, чтоб экранирование не надобилось в 90% случаев), кусочки json'а туда же

12) Макросы для оптимального разворачивания математических операций, сейчас люди мозги вывихивают чтоб две большие матрицы сложить "in place", ибо static operator + полагает что нужен новый объект

13) Свой new (из пула например), delete (в дебаге например ещё и заставляющий проверить GC что ссылок на объект нет и ассертящий если вдруг нашлось)

14) parallel for, parallel foreach и т.п. — там вообще все методы принимают лямбды, а ведь можно чисто и красиво

15) переписать linq to objects на макросах, так чтобы простые локальные случаи работали без потерь перфоманса (типа .Where().Sum(), .Any(), .First() и т.п)

16) Синтаксис для выноса контрактов в объявление метода, включая ссылки на контракты (например группа методов не должна нарушать один и тот же набор инвариантов).

17) Собственные контракты, например часто встречаются методы которые можно вызвать только когда лок уже взят. Хотелось бы повесить на них requires lock SyncRoot, и дальше чтоб компилятор позволял эти методы вызывать только из под lock(SyncRoot) или из методов которые ограничены таким же requires, нарушение ограничения — ошибка компиляции

18) Ключевые слова для функций захватывающих объект "для себя", например часто встречаются конструкторы принимающие массив, и они внутри себя делают Array.Copy потому что не знают, будет этот массив меняться внешним кодом, или нет. Был бы макрос например "Vector(captures double[] row) { this.row = row; }", и компилятор во внешнем коде делал "undefined" входному значению, или бил бы по пальцам за попытку туда писать, или же наоборот, при обнаружении попытки записи варнил а на вход передавал копию — тут уже возможны варианты. А то сейчас есть приложение которое 5% мемори траффика генерирует на такой вот фигне.

Это сходу. А если начать думать...