Comments 5
Using declarations — это то, ради чего я готов простить кучу всяких новых неоднозначных фич и сразу перейти на 2019 студию после релиза.
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? Очень сомнительно. Скорее появилась еще одна возможность накосячить.

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


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

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

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

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

Information

Founded
Location
США
Website
www.microsoft.com
Employees
Unknown
Registered

Habr blog