Microsoft corporate blog
.NET
C#
Programming
Comments 5
0
Using declarations — это то, ради чего я готов простить кучу всяких новых неоднозначных фич и сразу перейти на 2019 студию после релиза.
0
and their contents are disposed at the end of the current statement block

То есть теперь будет проще ненароком увеличить время жизни disposable-ресурса? Текущий блочный стиль использования using делает очевидным место уничтожения ресурса — закрывающаяся фигурная скобка не даст соврать. С using declarations же, как я понимаю, добавление дополнительных строк кода в конец текущего блока будет зазря откладывать вызов Dispose, несмотря на то, что этим строкам ресурс может уже и не требуется.


Легко представить ситуацию, когда нужно в уже написанный метод спустя некоторое время добавить какое-нибудь логирование. Разработчик (не обязательно автор) открывает код, пробегает его глазами, не замечает using declaration где-то посередине (ибо он никак не выделяется теперь отступом от нижележащего кода) и с радостью вписывает последней строкой отправку логов. И теперь вызов Dispose пойдет после того, как лог запишется. В зависимости от внутренней гибкости/сложности/продвинутости системы конфигурации логов вызов может отрабатывать как мгновенно, так и с существенной задержкой, если под капотом разворачивается в синхронную запись на диск/БД/внешнюю службу. А у нас под using стояло открытое соединение с БД… В итоге можем получить плавующую непонятную проблему, когда на dev-окружении все будет летать (потому что логи там толком и не настроены), а на prod внезапно все колом встанет из-за того, что пул соединений исчерпается, ибо время удержания соединения открытым станет зависеть от скорости работы совершенно не относящегося к соединению с БД кода.


Нужно отметить, что в случае блочного using можно запросто достичь такого же эффекта, внеся код внутрь using-блока, а не после него. Но сам дизайн работы с using-блоком предполагает сужение его настолько, насколько это возможно. Выделили ресурс, выполнили все реально необходимые с этим ресурсом действия и тут же его уничтожили. В коде четко видно место рождения ресурса и место его смерти. Теперь же место смерти неявное.


using statements always cause a level of nesting, which can be highly annoying and hurt readability

Nesting убрали, да. Улучшилась ли та самая readability? Очень сомнительно. Скорее появилась еще одна возможность накосячить.

0
Point(var x, var y) => $"({x}, {y})",


к чему приведёт такой код
Point(var x, var y) => x = y,

изменится property 'x' у объекта 'o'? это может быть очевидно, но я всеми руками за val вместо var
0

Да вроде не должно. Ведь это деконструктор, а после деконструкции x и y уже никак не связаны с объектом o — это просто переменные, в которые скопировалось внутреннее представление o.

Only those users with full accounts are able to leave comments. , please.