А ответ на второй вопрос какой?

Показать что типизация в шарпе архаичная и слабенькая)

И уж точно никогда не позволит писать так лаконично

И надежно. Ибо легаси. А что бы писать хоть чтото подобное - на помощь приходят типы в рантайме, аля рефлексия

Мне даже код не придётся писать, пример сразу нагуглил : docs.microsoft.com/en-us/archive/msdn-magazine/2014/february/aspect-oriented-programming-aspect-oriented-programming-with-the-realproxy-class#the-decorator-design-pattern

Я знаю как этот паттерн реализовывается в шарпе) это же не ответ на мой вопрос)

А, ну покажите
Только мой аргумент был другой, что на на шарпе писать просто

Пример даже конкретно этот кейс рассматривает - логгирование
Что не так?

Ну дело не в логировании было. Я ставлю акцент на том как сделать декоратор что бы он сохранял оригиналуную типизацию?

В шарпе ку бойлерплейта, логгеррепозиторий почти послеостью воучную прописан и если делать рефакторинг оригинального интерфейса придется и рукапи все типы подправлять. А частности как задекорировать лямбды или методы надежно?

Опять же логгеррепозиторий будет работать только с конкретным интерфейсом , а для других сущностей так же придется бойлерплейтить.

А в примере она не сохраняется?
Ну и раз уж пошла такая тема, искать преимущества одного языка и выпячивать их, встречный вопрос - вот выше там озвучен был Пойнт про то, что в жаве/шарпе/плюсах можно не задавать значения для полей класса. Причём этот Пойнт был озвучен в плане безопасности в сравнении с ТС - в тс их задавать обязательно
Но ведь в ТС есть partial, это не смущает? Что безопаснее, иметь 0 в неинициализированном поле, или undefined?

Чем больше когда сервисного, тем сложее выделить бизнес логику

)) ну опишите свойство ссылочного типа и посмотрите какое там значение по умолчанию)

Точно не undefined ;)

Это правда, да xD

А по поводу undefined - ts null safe яп, он не даст к полю обратится без явной проверки. И классно что эти вечные проверки так задалбывают что начинается складываться впечатление что модели с опциональными полями это чтото попахивающее и уже в твою доменную логику должны приходить целостные модели, без опций - и это мотивирует на написание хорошего кода. В си шарпе всем пофигу, в первую очередь компилятору

Но эта null safety есть только в ide, о чём не стоит забывать

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

Так в этом весь поинт null safety - давать гарантии на этапе компиляции, а не рантайма. Мне не известны null safe япы в рантайме