Do more with patterns in C# 8.0

[saltukkos]

Using declarations — это то, ради чего я готов простить кучу всяких новых неоднозначных фич и сразу перейти на 2019 студию после релиза.

[sungam3r]

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? Очень сомнительно. Скорее появилась еще одна возможность накосячить.

[kxl]

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

к чему приведёт такой код

Point(var x, var y) => x = y,

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

[sungam3r]

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

[finlandcoder]

Тем временем в С++

constexpr explıcıt Point(const Point const && const p) throw;