This project is read-only.

Feature Request: using declaration

Topics: C# Language Design
Jun 7, 2014 at 1:36 PM
Edited Jun 7, 2014 at 1:38 PM
We use the using statement to easily and safely dispose of resources. using statements are always blocks. This can be syntactically inconvenient. Maybe we can just do it like this:

using (var stream = new FileStream(...)) {
using stream = new FileStream(...);
The dispose would happen when the variable stream goes out of scope.

I am an active answerer on Stack Overflow and I am amazed that in 2014 people still don't routinely use using. I use it for everything I can because there is no reason not to. Maybe more people start to use it once it has less syntactic overhead than a stream.Close() call.

Maybe people are afraid of nesting too deeply with multiple usings because they don't know that they don't have to nest. They can just place the using statements like this:
using (var a = ...)
using (var b = ...)
using (var c = ...)
 Run(a, b, c);
This is best-practice. I often see that people do this instead:
var a = null;
var b = null;
var c = null;
try {
 a = ...;
 b = ...;
 c = ...;
 Run(a, b, c,);
finally {
 if (a != null) a.Dispose();
 if (b != null) a.Dispose();
 if (c != null) a.Dispose();
Which is clearly inferior. Now they can write:
using a = ...;
using b = ...;
using c = ...;
Run(a, b, c);
A problem with this syntax would be that it is not immediately obvious where exactly the dispose will happen. This might result in early disposal. But such bugs are always noticed during testing so it is not too bad.
Jun 7, 2014 at 6:07 PM
From what I can tell, you want to lose the parentheses and allow a semicolon after the using statement. I guess I'm unclear in what way
using stream = new FileStream(...);
is clearer than
using (stream = new FileStream(...))
The only thing which would compel the use of { } blocks on a using which guards only a single statement would be local coding standards imposed by one's employer; if there is an argument to be had, it would be with the people imposing such standards. My own feeling with regard to brace usage is that if one's convention is to open braces at the end of the line controlling the block, then braces should be mandatory for single-statement blocks with a narrow exception(*); if open-braces are placed on lines by themselves, then braces should be optional. Personally favor the VB.NET syntax which achieves the vertical spacing as the pushed-back brace form, but without what I view as an ugly open-brace character.

(*) Even when convention pushes braces to the preceding line, I favor omitting the braces an if statement in cases where the condition and consequent action are brief enough and sufficiently related to fit on one line both syntactically and semantically (e.g. if (x > 23) x = 23;, where both the condition and consequence deal solely with x, and where expanding such a statement to three lines could lead to vertical bloat (e.g. if it's necessary to peg three variables with minimum and maximum values, using six lines would IMHO be cleaner than using 18). I suspect that while the creation of using variables and the method invocations upon them are likely to be too verbose to justify squishing everything to one line, perhaps one could justify using a differently-sized indent when a control statement affects just one line.