Это неудачный скриншот из видео. Там этот код постоянно переписывают, отрываясь на рассказ о конструкциях языка. Большую часть видео код на нём некомпилируемый. Через несколько секунд его перепишут на switch(v) {case int i: ...}
Конечно можно. Вы у себя в коде будете использовать все эти l_ и m_, и этим самым решите для себя проблему. А команда Roslyn не хочет рефакторить свой код и выслушивать претензии коллег из EF. Вот и осторожничают.
Там выше пример с функцией match. Имя, как имя.
Сколько новых ключевых слов было добавлено в C# с первой версии и сколько из них ломали компиляцию существующего кода? Вот про это я и говорю. Добавлять можно, но трудно.
Поведение старого кода новым компилятором, кстати, ломали несколько раз, но это были очень редкие и трудновоспроизводимые ситуации. Хотя, все помнят редизайн foreach, там получилось так себе.
Вы мне доказываете, что проблемы можно решить, а я вам говорю, что дизайн-команда языка пытается их избежать. Отсюда и неловкий синтаксис у паттерн матчинга.
Мне кажется, что приоритетнее иметь компилятор, который не ломает существующий код. Что я и пытаюсь донести в этой ветке. Иначе будет у нас, как в Python мире, где существующий код с 2.7 на 3 не перенести. Никто там автоматической конвертацией не занимается, если этого можно избежать.
Добавить к багам транслятора ещё и потенциальные баги самодельной тулзы на розлине (стабильной версии которого в те времена не было)? Увы, это очень дорогое и сомнительное удовольствие.
При этом переезд с .NET 3.5 на 4 тот проект пережил без особых проблем.
К вопросу об автоматической миграции: работал я как-то в компании, которая 30 лет писала банковский софт на самопальном процедурном языке с макросами.
Потом они этот код конвертировали в C#, завернули в виртуалку и начали поставлять клиентам. Там название части классов были из оригинального кода (на голландском и с сокращениями), а имплементации макросов были названы рандомными строками.
При этом кода там было очень много. Решарпер на этом вешался и валил студию, MSBuild собрать солюшн не мог, приходилось городить многошаговые скрипты сборки. Посмотрел бы я как они автоматически исправлялют несовместимости компилятора в таком коде. Тем более, что все фиксы там делались в конверторе, который тупо регенерил весь солюшн заново.
Такой вот ад программиста. Это, конечно, экстремальный случай, но и без него в мире существует много софта, рефакторить который — себе дороже.
Например из этого поста. Эти символы включают флаги для MSBuild. Без них студия будет выводить сообщения об ошибках с подсказками о том, какие ключи нужно добавить.
Error CS8058
Feature 'local functions' is experimental and unsupported; use '/features:localFunctions' to enable.
* Nested local functions extend the language to support declaration of functions in a block scope (use /features:localFunctions)
* Pattern matching extensions enable many of the benefits of algebraic data types and pattern matching from functional languages (/features:patterns)
* Ref returns enable functions to return values by reference (/features:refLocalsAndReturns)
Что это за non generic `HashSet` у вас? Допустим, это что-то стороннее, но это же не решает проблему автора, вы просто убрали типизированную коллекцию в аналог `HashSet<object>`
К сожалению, они вынуждены балансировать между удобностью-читабельностью и обратной совместимостью. Большинство вариантов удобного синтаксиса являются валидным кодом на С# младших версий.
when
, аcase 1: case 2:
и раньше работало.switch(v) {case int i: ...}
l_
иm_
, и этим самым решите для себя проблему. А команда Roslyn не хочет рефакторить свой код и выслушивать претензии коллег из EF. Вот и осторожничают.match
. Имя, как имя.Сколько новых ключевых слов было добавлено в C# с первой версии и сколько из них ломали компиляцию существующего кода? Вот про это я и говорю. Добавлять можно, но трудно.
Поведение старого кода новым компилятором, кстати, ломали несколько раз, но это были очень редкие и трудновоспроизводимые ситуации. Хотя, все помнят редизайн
foreach
, там получилось так себе.Вы мне доказываете, что проблемы можно решить, а я вам говорю, что дизайн-команда языка пытается их избежать. Отсюда и неловкий синтаксис у паттерн матчинга.
При этом переезд с .NET 3.5 на 4 тот проект пережил без особых проблем.
Потом они этот код конвертировали в C#, завернули в виртуалку и начали поставлять клиентам. Там название части классов были из оригинального кода (на голландском и с сокращениями), а имплементации макросов были названы рандомными строками.
При этом кода там было очень много. Решарпер на этом вешался и валил студию, MSBuild собрать солюшн не мог, приходилось городить многошаговые скрипты сборки. Посмотрел бы я как они автоматически исправлялют несовместимости компилятора в таком коде. Тем более, что все фиксы там делались в конверторе, который тупо регенерил весь солюшн заново.
Такой вот ад программиста. Это, конечно, экстремальный случай, но и без него в мире существует много софта, рефакторить который — себе дороже.
Думаю, что это, как всегда, временное название.
Тут есть список ключей для __DEMO__:
* Nested local functions extend the language to support declaration of functions in a block scope (use /features:localFunctions)
* Pattern matching extensions enable many of the benefits of algebraic data types and pattern matching from functional languages (/features:patterns)
* Ref returns enable functions to return values by reference (/features:refLocalsAndReturns)
Если вам интересна эта тема, советую посмотреть трансляции API Review и почитать обсуждения Proposal в репозитории Roslyn.