10 худших моментов языка C#, которые прочувствуют только профи 

Чел, хорош , контент вообще в кайф!! Можно вот этого вот всего почаще❤❤❤

Замечательное видео) Внесу свою лепту (как человек что много лет пишет на чистом С/Ассемблере, а сейчас пишу этот комеет как С# фулстек) 1) модификаторы доступа - это годнота. Если не нужно, то не используешь "лишнее". У С\C++ вместо internal вообще static (это при том, что там есть external) Я выступаю за то, чтобы был максимально гибкий контроль за областью видимости, потому как много раз видел, как сужение области видимости просто "схлопывает" тонны кода на выхлопе компилятора. И таких инструментов, которые несут смысл как для программиста, так и для компилятора очень мало, если так подумать 2) Мне очень нравится, что вложенные типы видят приватные поля тех, что выше по иерархии. Благодаря этому можно очень красиво делать реализации Строителей. Если делать как по науке, то нужно подводить желаемый тип под интерфейс, в котором можно менять значения полей. И сам интерфейс хорошо бы спрятать, чтобы уши не торчали... а так, вложил один тип в другой и всё готово. Потому как руки всё равно потянтся проверить, а не будет ли у типа фабричного метода, если конструктор приватный Про путаницу с модификаторами доступа по умолчанию -- полностью солидарен 3) Дженерики - это прям беда. Столько раз себя ловил на мысли, что это какой-то кастрат плюсовых шаблонов, что аж неловко становилось Они ну слишком базовые. Есть попытки в метапрограммирование (те же where и всякие контр/ко/ин-вариантности), но пользоваться ими очень неудобно, когда нужно работать с иерархией этих типов Спасаемся базовыми типами, как и было упомянуто в видео) Но лично моя боль №1 -- поведение структуры с интерфейсами Это прямо дичь. Моментально рушится вся идея строго значимого типа. Плюс к тому очень много странных ограничений (нельзя давать полям значения по умолчанию, вне конструктора без аргументов, но как только ты этот самый конструктор определяешь, то ты рушишь целую вереницу оптимизаций, что заботливо для тебя выстроили авторы языка) А те же readonly ref struct я смог применть только в паттерне итератор. И работает это только из-за костылей с утиной типизацией... вне этого как только у тебя появляется хоть маломальски выстроенная иерархия типов и ты хочешь внести "перформанса" , то ты быстро обнаруживаешь, насколько же у тебя связаны руки. Либо рефлексия, либо переписывать всё в совсем другой парадигме Я бы добавил интерфейсу гарантию, что он представляет только значимый тип (с синтаксисом для такого поведения). По сути легальный и чистый способ для утиной типизации С# получился очень удобным прикладным языком И он может решать целый спектр задач Потому его сейчас как лебедь/рак/щука тянут в сторону обратной совместимости, рядом новые и модные практики с функциональщиной, а особняком системные программисты, которым нужон High Performance Ещё раз выражаю благодарность за видео и труд! Смотрю тебя с большим удовольствием)

Невероятно интересный видос. Большое тебе спасибо ❤

Мне пришлось перейти с C# на Java, ребят. Как же вы счастливы, ребят, вы не понимаете, насколько C# кажется прекрасным после перехода на джаву!

Хаха, я смог заполнить switch expression. Буквально всего то пара лет прошло) Теперь осталось запомнить синтаксис его паттерн матчингов.

Очень интересно! Спасибо)

очень хорошее видео, благодарю за труд

Не знал о некоторых проблемах даже, повезло-повезло. Спасибо, интересный формат!

Крутое видео. Спасибо за воркэраунды для некоторых проблем!

Отличный ролик 👍

Спасибо за видос!!!

Классный видос, лайк

Крутое видео)

Спасибо

Ух, про switch прямо в точку. Помню сходил на неделю в отпуск и напрочь забыл его синтаксис. Дело было года два назад, когда он только входил в обиход. По части модификаторов доступа - там еще file завезли) а где internal, там и InternalsVisibleTo, так сказать) P.S. На фразе «С деструктором все еще хуже. Во-первых, он у нас… есть» заржал и подавился своим смузи

Крут!!!

Спасибо за очередное полезное!) Никак не пойму как до такого уровня подняться. Ты не рассказывал про свой путь, что надо сделать? Не поступать в вуз, сразу стартапы, куча пет проектов и потом куча ком. проектов, не жениться (чтобы не отвлекали), с друзьями никуда не ходит и пр. Поделись лайф хаком, очень интересно!)

я десь рік тому стикнувся з 10-ю проблемою, тоді теж мало не здурів і майже постарів на 50 років поки дебажив, в кінці в мені щось перегоріло і я просто змирився що це так не працює, розбиратись в причинах вже не було ні часу ні моральних сил, просто переробив і забув. Ти зараз прям витяг на "світ божий" коварне зло приховане в пітьмі, яке паскудить життя багатьом. Вважай - ти рятуєш людям нерви і час для чогось більш прекрасного, так тримати👍

У меня как-то было веселье с перегрузкой методов. Уже не помню деталей, но идея была в том что было 2 версии метода и одна принимала энум, а вторая инт. В итоге я передаю энум, а вызывается версия с интом.

Дуже дякую. Корисне відео. Реквест на налаштування статичних аналізаторів. Тільки в студії, а не в цих ваших джетбрейнах!

Добротний відос. Тепер по пунктах 10) Все правильно, так влаштовані інтерфейси - я не хочу знати внутрішню імплементацію (вона взагалі може бути в іншій інтернал френдлі ассемблі, або замокана в тестах), а працювати лише з публічним контрактом, тому x і має бути 10 9) Теж логічно, але неочевидно - лише на досвіді трекаєш таке. 8) void - зло, a async void - ще більше зло :) 7) event - в топку, застаріло, краще юзати Rx. Конкатенація делегатів може бути корисною в маппері, наприклад, коли накидуєш на маппінг одного проперті декілька делегатів 5) Type inference - це біль C# та аналізаторів синтаксису. F# в цьому плані дуже органічний 4) protected - це біч ООП, коли писали все на Rich Domain Model, де дані та поведінка інкапсулювалися в самому класі і для модифікації функціональності лишалося засабкласитися з оверрайдами (привіт Template Method pattern). Pubilc модифікатор в інерфейсах юзаю лише тоді, коли далі йде дефолт імплементація - це дозволяє візуально відрізняти вже імплементовані методи від тих, які треба імплементувати в нащадках 2) Конструктор ще не можна передати як посилання на метод, типу .Select(Myobj.ctor) і доводиться писати .Select(_ => new Myobj()) 1) Вітаю, ти віднайшов property injection :) В Blazor є відповідний атрибут [Inject], де можна врізати свій сервіс без зміни всіх нащадків

К обходу 7-й проблемы в пример можно ещё библиотеку System.Reactive привести. Там тоже логика помещения подписки в IDisposable используется. Также есть механизмы адаптации классических событий. Но, с другой стороны, это уже не Subscriber/Puslisher, а Observable/Observer получается.

Не понятно,но очень интересно)

Хорошее видео, насчёт конструкторов с абстрактными классами полностью согласен, а так же с асинхронными и не асинхронными перегрузками. Как по мне уже давненько пора отказаться от явного применения Task с асинхронными методами и отдать это на вотчину компилятора, т.к. нам, как правило, нужен дженерик объект таска, а не сам таск,🤘

Хорошее видео, Новый switch case конечно же это ужас. + в последних версиях шарпа очень много сахара, это не очень радует.!

На счёт конструкторов: можно сгенерировать пачку паршл классов в которых определяется конструктор. Либо иньектить зависимости в свойства. Ну а 50 тестов всё ровно придётся изменить.

По поводу последней проблемы: в Rider есть удобная функциональность, добавляющая аргументы в функцию, если в одном из мест вызова дописать этот аргумент. Это же применяю и при добавлении нового параметра в базовый класс. Так же можно через меню рефакторинга это же сделать - в popup окне вписываешь название и типа аргумента, и он появляется во всех наследниках. Не знаю, как там в VS - давно не использовал

У меня проблема, которая на первом месте, была в ts'e, только там в конструкторе было 17 сервисов, в родитель я передавал 10, у того был еще один родитель с 4 параметрами. И к этим четырём параметрам надо было добавить пятый... Энивей у свитч экспрешена первое место у меня

с парой проблем сталкивался,решения такие же были,как и ты предложил. но давайте посмотрим правде в глаза - многие из новых фич языка (вообще) крайне сомнительны и спорны( те же интерфейсы с реализацией по умолчанию)

11:47 Плачу на этом моменте. Сколько часов было убито в борьбе с этим!

1. В С++ если констуктор наследника будет по аргументам повторять базовый + без тела (только вызов конструктора базового класса), то можно написать внутри класса наследника class Derived : public BaseClass { using BaseClass::BaseClass; }

топ1 проблему прочувствовал буквально на днях, согласен с ее нахождением в топ1

На счет первого пункта. Если я не ошибаюсь , то можно вместо класса агрегатора и использовать атрибут , наподобие инжект в ангуляр, я недавно натыкался на статью. Суть в том что тебе вообще не надо писать зависимости в наследниках , а лишь указать аттрибут в базовом и он будет применять все di в наследниках

Чет так заслушался на вступлении, что показалось, что начала какого-нибудь фильма от Гая Ричи)))

Насчет конструкторов вариантов не особо много, средствами языка сейчас, как вариант, только добавлять вторым конструктором, и вызывать из первого с созданием нужного класса. Но если нужно какую-то зависимость протаскивать, то тут без изменений никак не обойтись. Жаль райдер не умеет сигнатуры всех зависимых конструкторов обновлять. С языковой конструкцией не хватает какого-то наследования конструкторов, возможно. Так, чтобы если есть класс A с недефолтным конструкторов, то в классе B : A, он сразу был бы доступен, с возможностью переопределения через override. Так, если бы в наследниках не было бы специализированных конструкторов, тогда кода пришлось бы меньше лопатить. (Но если в наследниках есть дополнительные параметры, то всё равно фигачить придется) По-моему тут особо вариантов нет, если появляется необходимость какую-то чувствительную часть кода подергать, то к этому надо быть готовым. Вариант с моделькой с сервисами в приведенном примере считаю перебором. Если у базового класса много зависимостей, которые ещё и часто меняются, и не нужны наследникам, то это скорее всего признаки плохой архитектуры.

Использовали сложение делегатов в продакшене. Был парсер документов, который менял состояние в зависимости от положения в документе, и на разных состояниях нужно было обрабатывать токены одним или несколькими анализаторами. Соответственно был словарь состояние-делегат, где делагат не обязательно один анализатор, а может быть несколько с разной логикой. И не то чтобы это было бы сложно сделать без суммирующихся делегатов, но если они уже есть, то почему бы их не заюзать.

про гит в точку

Половина проблем просто надуманы. А насчёт массивов и генериков и общего кода что мешает использовать интерфейсы? У массива спокойно есть генериковый интерфейс IReadOnlyList`T, например.

Речь конечно про с# но добавлю по поводу косяков, в entity framework 7 завезли column json, только нельзя чтобы классы в этих колонках имели поле с названием id, будет вылетать ошибка при запросах , так как конфликтует как я понял с ихним десерелизатооом .

Первое место жиза, но только не понятно как настроить его для DI. Есть видосы на эту тему? Еще тоже бесит что он автоматом не указывает дженерик, я думаю это могут добавить IDEшках как авто заполнение.

А можна лінк на оригінальну статтю ? Чи на презентацію, якою ти користуєшся ?

А первая проблема у меня чаще решается практически полным отсутствием наследования, если честно. Если там какая-то общая логика, то её можно вывести в какой-нибудь класс-хелпер. С наследованием в принципе очень легко отстрелить себе ногу не в одном месте, так в другом. Была весёлая история, когда переопределили то ли Equals то ли GetHashCode в базовом классе сущности и у нас то ли работа с базой, то ли какие-то вычисления взорвались от этого в совсем другом месте

На счёт 6го места... default там не впихуемый т.к. в этом случае будет сравнение на значение по умолчанию

Вот женерики да, прям иногда хочется хитрых проверок навернуть, и так чтобы "оно само" потом работало при использовании. А в итоге получаются костыли с кучей наследований. А на счёт конструкторов - у меня была идея, что если бы на вход можно было передавать какой то класс (или анонимный тип) который может деконструктиться в нужный список аргументов прямо при передаче в конструктор. var arguments = new SomeClassArgsRecord(a, b, c); var someClass = new SomeClass(arguments.Deconstruct()); // new SomeClass(a, b, c)

По поводу массивов (их необобщенности) и конструктора - это же следствие истории создания шарпа, как сводного брата Java.

1ое место. Был такой случай на первой самой работе. Был самым зеленым джуном среди сеньоров. И потел каждый раз, когда в процессе багфикса приходилось трогать "то что работает" и было написано опытными программистами. Но в один прекрасный день попался баг, в качестве решения которого, было необходимо добавить в конструктор базового класса некий объект. Как сейчас помню, звоню наставнику и несколько раз уточняю, что "пук среньк надо вот в базу добавить вот это, но там наследование 5> потомков и типа мне надо каждому из них в ктор пробросить этот тип..???" "- Да"....

Обычно с коллегами обсуждаем новые фичи... и часть просто не используем))) чтоб не бесили. Как в шутке - "если вам не нравятся гейпарады, прекратите в них участвовать"

Имхо косяк #1 - это неудобство отписки от ивентов. Особенно с анонимными методами

Насчет свитча орнул) Пока мы - джсеры, страдаем от того что из нашего языка пытаются сделать шарп постоянной копипастой паттернов от туда, то шарписты страдают от того к ним завозят паттерны из джса))) З.Ы. Для тех кто не въехал, в джс свитч кейс как он выглядит в плюсах или хексе это антипаттерн, который заменяют объектом, каждый из свойств которого является кейсом, который стрелочной функцией возвращает результат для кондишена

С дженериками конечно боль, особенно после котлина где можно сказать "тут у меня интерфейс с неважно каким дженериком IMyInterface".

Кому как, у меня каждый раз болят дженерики из 3-го места, ну и с ними всё время паровозиком идут массивы из 1-го места. Это массив, список, словарь, как их понимать? И каждый раз либо изобретаешь с нуля, либо тащишь свою библиотеку с решением. Создаёшь в каждой библиотеке модуль Autofac, автоматчески регистрируешь вот это всё... а под капотом боль от "а класс реализует дженерик интерфейс", а "интерфейс наследует этот дженерик интерфейс"? А атрибут? А как из этого безобразия создать инстанцию?... 🤯

решение на топ1 крутое!

Есть ещё реализация интерфейсов по умолчанию. Когда на это первый раз смотришь вообще мозг ломается

про 9: Правильным решением будет использование асинхронных методов у IQueryable. У IEnumerable таких нет.

Я не очень понял про 9 пункт, вроде это же можно запомнить, почти как "жи-ши", не тащи тонны данных через enumerable, юзай силу, Люк.

Проблему с 1 места мне доводилось решать похожим способом, но со временем я понял, что лучше будет сделать отдельный класс RepoMappedEntittiesBase, который собственно и добавляет новый функционал и будет требовать уже для новых наследников передачу нужных данных. Тем самым мы и не нарушаем Open-Closed принцип. Как по мне оба подхода имеют смысл, т.к. все зависит от контекста того, какие изменения вы планируете внести.

Разложил сисярп по фактам, так ему 😅👍

По поводу первого места. Мне не понятно, по какой причине нужно постоянно переопределять конструкторы. Этой проблемы могло бы не быть, если бы не пришлось этого делать. При этом они не обязательно что-то делают, они просто перебрасывают параметры и просто существуют. Возможно есть этому объяснение, которое я не знаю и это всё оправдано. Но например в php такого нету, конструктор можно сделать один раз в родителе и иметь кучу наследников, которые будут пользоваться уже существующим конструктором. В тайпскрипте тоже

А в целом - да, вроде косяков хватает, но с многими или вообще не сталкиваешься или они лишь чуточку портят жизнь. А потом садишься за Питон или того хуже Джаваскрипт и стреляешь себе в ногу на пустом месте. Например в Питоне свойства объекта в конструкторе надо писать через self., иначе это будут статические свойства. Я разок так выстрелил себе в ногу. Вон стильно-модно-молодёжный Rust из коробки не имеет yield, пользуйтесь библиотеками :( Подозреваю что если пописать на нём подольше, то тоже можно всякого найти

Андрей, а тебе еще не говорили, что ты реально крут? :)

А як же record class, який може бути positional (immutable) або звичайним (mutable). Здавалося б, навіщо?

По девятому пункту (IQueryable и IEnumerable): если такая проблема появляется на продакшене, то у вас большие проблемы с тестированием своей работы и язык тут не при чем. Подобные проблемы у вас будет при использовании любого языка

Тоже отмечу жуткую боль от дженериков. Они вроде бы неплохие, но не хватает кучи инструментов (по типу усилений ограничений по иерархии интерфейсов, например, и других). Тему самой главной проблемы (№1), честно говоря, не очень понял. Как изначальную проблему (наследование реализаций в программировании бьёт по рукам ещё со времён множественного наследования), так и решение-костыль (оно же усложняет чтение класса и параметров конструктора). Не совсем понимаю контекста, но разве использование Type Object паттерна не излечит от этой проблемы? Или декоратор, опять же.

По поводу 8. Про void это не конкретно шарпа беда, а вообще всех языков, генеалогическм восходящих к Си. Поэтому в си возвращают 0, что значит, что процедура выполнена успешно.

30:00 а ещё я в райдере когда копирую файл с классом, вставляю, меняю ему имя, и оно не меняет имя класса внутри! и его приходится менять в двух местах!

спасибі за роботу. А можна приклад як навчити DI створювати об'єкти як в топовій проблемі 🙃🙃🤗🤗

Немалую часть проблем фиксят линтеры и копайлот. Лично мне не нравится, что когда у меня есть интерфейс с синхронным методом, я подключаю асинхронную реализацию (хз, например перехожу на новую бд, к которой драйвер предоставляет возможность делать асинхронные вызовы), так вот теперь эти таски пронизывают код полностью. Придётся переписать все вфункции, чтобы они работали с тасками. И это прям вымораживает. Какого чёрта вообще моя бизнес логика должна знать синхронный или асинхронный вызов порта она должна вызывать (например в гексагональной архитектуре)? Бл не должна зависеть от инфра уровня. А тут язык подсовывает явную зависимость.

там ещё модификатор доступа file завезли в 11 шарпе)))

Чем опытней разработчик тем грандиозней ляпы он совершает.

Ну. Большая часть это не проблемы языка. Но с чем согласен, это с войдом. Войд - это реально боль, если тебе нужно библиотеку для команды делать. Приходится либо одинаковую логику мутить, либо вводить какое-то извращение в духе Unit, Empty, Nothing и всем говорить, что оно есть. И проблема со вторым подходом, в том что шарп начинает ворнинги сыпать, дескать ты результат не используешь, а ну как сделай Nothing _ = Lib.Execute();

На счёт 8го места. Видел затычку с классом Void с приватном конструктором, а методы с таким типом просто возвращают null

я таки вырезал кусок про войд😁

Для топ 1 возможно **args из питона подойдут, но лучше без них))

А можно топ1 решить аннотациями, например добавить property в базовый класс с аннотацией [Inject]. Если что, я не настоящий волшебник....

Открой для себя Nemerle. В нем в 2006м недостатков было меньше чем в C# в 2023м.

"главная проблема №1" - пустой каприз и я бы даже сказал дилетантство. Если ты так смело хочешь залезать в базовый класс и чтобы потомки ничего не заметили, ты явно ошибся методологией - тут один пусть, в Бейсик. 😆 Базовый класс ОБЯЗАН ломать потомков, ибо так и задумано: если ты что-то изменил в предке, значит потомки уже не могут рассчитывать на прежнее поведение и должны сами измениться. Просто представь современный автопром: базовая конструкция моделей ОДНА, а сверху нахлобучивается купе, седан и т.п. И тут бравый анжанер удлинняет колёсную базу. Как думаешь, модели не заметят этих изменений? :)

25:48 думаю кто можно было отойти, создав ещё один пустой не дженерик интерфейс, и наследовать его от дженерикового, и уже в is проверять на не дженериковий интерфейс

23:20 всмысле 6 модификаторов? а file?))

Відносно першого місця, можна засетити дефолтом значення в null: (SomeType sometype, IMapper mapper = null)

Третья претензия вообще чистон непонимание. Что будем делать вот тут? class A : IX, IX Что тут даст is IX ?

Знаешь почему синтаксис switch такой? Потому его решили перенести один в один с Rust😂

Уже лет десять прогаю, даже половины из сказанного не использовал.

Новый C# это Kotlin, расходимся

Синтаксис свича, кстати, реально противный и не очень понятно почему его сделали таким. Я его до сих пор толком не помню и приходится гуглить

Из относительно новинок ещё можно вспомнить проверку на null через is (pattern matching), а не == Способ через is рекомендуется самим майкрософтом, чтоб случайно не попасть на переопределение оператора == И всё было бы хорошо, если б этот is работал везде. На текущий момент его нельзя использовать в expression-ах (в отличие от лямбд, что дико путает). Т.е. во всех linq-выражениях на is будет ругаться... По итогу в коде получается сборная солянка, а ты постоянно натыкаешься на ошибку от IDE в linq... 🤬

Ну что, опять НЛП в действии, позавчера ревьювил проект где ребята как раз Queryable передали в метод который принимает IEnumerable:)

я думав, що я один такий не можу запам'ятати switch expression)

Сравниваю с котлин. 1. Проблема 10 - нету в таком виде, в перекрытых классах нельзя ставить дефолты 2. Проблема 9 - и есть и нет, да можно не то расширение вызвать, но нет идеи query able для внешних вызовов. Но проблема рантайма зато есть. Проблема есть и даже хуже но не из за языка, а jvm, jar с одинаковыми классами 3. Проблема 8 - нету, Unit (void) это тип 4. Проблема 7. - нету так как благо нет понятия событий 5. Проблема 6. - нету свитч (when) сразу был выражением, и не требуется break, как в golang, по умолчанию брек. 6. Проблема 5. - нету, вывод типов умеет из параметров выводить 7. Проблема 4. - другая, мне совсем не нравится, что в котлин по дефолту паблик, я бы предпочёл приват. Но дефолт тем не менее всюду один 8. Проблема 3. - другая, тоже сложности с апкаст можно сделать, зато рефлексия в куче контекстов не сработает ибо type erasure, генерики мне чуть больше в шарпе нравились, но правда хаки со звёздочкой там не работают 9. Проблема 2. Нету, явное ключевое слово constructor + init. Но в целом я предпочитаю приватные конструкторы и факторки в компаньонах 10. Проблема 1. Такая же. Специфика модели классов которая у джавы и Шарпа почти одна. Поэтому стараюсь меньше наследования, больше композиции, меньше конструкторов, больше фабричных методов

погоди, а если базовый класс унаследовать от типа передаваемого аргумента и не передавать этот аргумент... как вариант... не утверждаю...

по поводу конструкторов -- наследование зло)) даже если ты и заюзаешь предложенный воркараунд, это не решает главную (и по факту единственную) проблему -- ты всё равно поменял поведение 50ти наследников, только теперь ты об этом скромно умалчиваешь в своём PR. не надо так делать. если зависимость какая-то опциональная, то можно поменять абстрактный класс на интерфейс с дефолтными реализациями и туда докинуть приватный геттер с дефолтной реализацией возвращать какой-нибудь стаб или нулл, а дальше уже по контексту. энивэй, сама по себе проблема больная, но она больная не просто так.

Я нашёл для себя, что 3 "самых худших момента", мне были уже знакомы и я так или иначе с ними сталкивался 🤯 Ну и остальные по мелочи знакомы были, хы. Я шо профи?

Проблема №1 реально боль, но предложенное решение - это антипаттерн "God object". Нет, это не решение) Продолжаю страдать...

Зачем слайды на английском? %) И вы похоже упорный девелопер - спеллчекер пытался направить на путь истинный, подсвечивая "Finilizer", но не смог победить :D Ну и "mension" тоже

Занудничаю: «упоминание»: Mention, не Mension

Тема недоделаных дженериков раскрыта не до конца. Стандартные коллеккции не реализуют коваринтность, нет нормальной контрваринтности типа возвращаемого значения в реалилизциях методов базового класса. Нельзя сделать where T is SomeAbstractClass - нужно для SomeAbstractClass делать интерфейс ISomeAbstractClass. В джаве это реализовано гораздо лучше. Благо на бэкенде магия джеренриков нужна очень редко.

Объяснение 9 невнятное, запутанное и не объясняет происходящее. А так видос зачётный.

как создать обобщенный класс )) обобщенный метод можно

"Современные" языки не проще, они еще просто не столкнулись с теми проблемами, с которыми уже десяток лет сталкиваются разрабы. Ваше утверждение как слова Бендера из футурамы про казино.

Ну, на самом деле многие ситнтаксические особенности C# унаследовал от C++, как это ни странно. Подозреваю, что бы облегчить переход первым девелоперам с С++ на C#. Да, как показывает практика, такой подход больше навредил чем помог. Но когда ты создаёшь новыя ЯП с нуля в условиях жесточайшей конкуренции с Java, который уже является отраслевым стандартом, то максимально простой переход девелоперов на этот язык является чуть ли не основным требованием.

Я конечно понимаю прикол 42, но возвращайти пожалуйста просто дефолт в таких случаях.