Using statement parity with block

[lcsondes]

Related to #114 #1174

I can write a using block with a variable in it:

using (var x = GetSomethingDisposable())
{
}

Or no variable if I never access it other than the hidden Dispose call:

using (GetSomethingDisposable())
{
}

In the current C# 8 preview, I can also write a using statement with a variable:

using var x = GetSomethingDisposable();

However I cannot omit the variable if I don't need it:

using GetSomethingDisposable(); // doesn't compile

I'd like to request making the last example valid.

[Joe4evr]

Just use a discard:

using _ = GetSomethingDisposable();

[issafram]

This doesn't work.

[andre-ss6]

This has came up before on the original issue. This would be useful for situations like setting up logging. The answer then was also to use discards. However, as mentioned there, littering the code with using var _ = is honestly worse than writing it the block way. After this, the discussion ended with someone saying that when they see this kind of code (logging), they just delete everything... so... yea, great.

In one of the codebases in my company, we also use using to setup logical scopes, and having the ability to ignore the return value with this new feature would also be useful there.

I don't know if I'm missing something, but in the end I see the original feature being mostly useful for the proverbial, ever-repeated example:

public void EveryoneUsesAdoNetNow()
{
    using (var connection = new SqlConnection(connectionString))
    using (var command = connection.CreateCommand())
    {
            // setup
            using (var reader = command.ExecuteReader())
                // do stuff
    }
}

... (which is not a lot)...
... And to confuse people because of semicolons.

I think there are many other valid use-cases that could benefit from the feature if this was allowed.

[DavidArno]

... having the ability to ignore the return value ...

That is literally what discards are for. The reason for using discards, rather than just allowing the value to vanish into the ether is because the latter case is a source of some hard-to-find bugs. Ideally, this would be retrofitted to method calls, so that for example,

stream.Read(buffer, offset, bytesToRead);

would be a compilation error. But that would be a breaking change. So we have to rely on analyzers to report those instances instead. However new features, like using statements, can be protected in this fashion from the outset.

... littering the code with using var _ = ...

1. There's no var there. It's not a variable declaration, it's a discard. So it's _ = …
2. If you are littering your code with them, then something is going wrong. Ignoring return values should be the exception, not the norm.

[ghord]

I strongly disagree that using discards is fine. IMO code looks much much better with proposed change and shows the intent clearly. You don't force people to use discards with normal method invocation, it should not be required in this case either.

[DavidArno]

@ghord, thankfully the language team disagrees with you.

[ghord]

The issue is that in the case of method, you can simply return void if return value is not necessary, but there is no "void disposable" way to write a method (i.e. consumer should not care about the result of method, only that it runs some code at the end of scope).

[lcsondes]

Discards don't work either:

using _ = GetSomethingDisposable(); // error CS1001: Identifier expected

[Joe4evr]

Okay, that looks like a bug.

[DavidArno]

Yes, I agree with @Joe4evr that that looks like a bug as I'd expect that to work.

[lcsondes]

Definitely, since using(_=Blah()){} also works, but additionally using(Blah()){} also works so I'd expect using statements to support everything that an "old using" could do, supporting some expressions but not all of them at least to me is a very arbitrary and contrived limitation. It doesn't even need to be a method call: var x = Blah(); using(x){}

You're already explicitly stating that you're interested in what the method returns by having the using there so I wouldn't worry about ignoring return values in the discardless form personally; adding a discard there is just extra syntax that doesn't give you much beyond what the presence of using already does. Both mean that you want to Dispose of what's returned but aren't interested in the object beyond that.

What is in fact dangerous is just doing ThisReturnsSomethingDisposable(1,2);, but that happens to be perfectly valid with no warnings since C# 1, and in fact is sometimes even recommended, such as Tasks where you're supposed to not Dispose of them in 99% of cases.

[andre-ss6]

If you are littering your code with them, then something is going wrong. Ignoring return values should be the exception, not the norm.

I don't think there's anything wrong.

As I said, there is a codebase in our company where we use using as a scope mechanism extensively for logging purposes (Serilog's LogContext.PushProperty()) and for setting up logical contexts. This is definitely not uncommon and has came up before on the discussion.

For background: this code is from a safety-critical system, where a bug could affect the lives of thousands of people. Thus, we put as many logging info as we can so that, when a bug pops up, we take as little time as possible to figure out what caused it. And so it's not like we can -- like someone suggested in the original issue -- just "delete everything". We've also did an analysis on how this new feature would impact our code and we were happy to see that we would be able to replace a lot of the usings there with the new syntax.

So we have to rely on analyzers to report those instances instead. However new features, like using statements, can be protected in this fashion from the outset.

Although I agree the language would be better off forcing people into do something about return values, I think using that as basis to not implement this is not valid for four reasons:

1. You'll still be able to use an analyzer, just like today. How much % of your entire codebase will really consist of using var =? I'm certain it will be in the lower percentiles -- and I think that's an understatement. So the vast majority of code will have to be checked by analyzers anyway. What difference would it make that only this tiny portion is actually checked by the compiler?
2. It is based on a false equivalence since, as @ghord said, there is no way to write a "void disposable" method. And yea, of course we won't anyway, because...
3. The consequence of "forgetting" the return value here is not any bigger than in any other situation, so there's no need for any alarm. And in fact, one can argue that it's actually smaller, since, as @lcsondes said, just by having the using there you've already stated your intention of what to do with the return value. This is not the same as writing DoSomething(); GetDisposable(); return; -- which, note, is valid C#;
4. In the original issue, a concern about a much more prevalent issue was presented: removing the semicolon changes the meaning completely. The argument used there is that we should not stop language development because of inexperienced devs not knowing how to use features. I think the same argument not only also applies here, but even more strongly because of the three aforementioned points.

[TheUnlocked]

I'd expect using statements to support everything that an "old using" could do, supporting some expressions but not all of them at least to me is a very arbitrary and contrived limitation.

To add to this, if I were a C# programmer who wasn't keeping up to date on the intricacies of the new C# language changes and saw using GetSomethingDisposable(); not work, I would probably either:

1. Spend some time searching StackOverflow for why this wasn't working and then get somewhat annoyed that this was just an arbitrary limitation that was inconsistent with code that I had written in the past;
2. Or I would decide that the new language feature probably didn't do exactly what I thought and just not use it at all.

Neither of those are great outcomes, and they're pretty easily avoidable by simply not imposing the limitation.

[MithrilMan]

so, any official statements about the bug that using _ = GetDisposable(); doesn't work?
CS1001 Identifier expected

that's quite frustrating

[lcsondes]

I'd still argue that _ = conveys the opposite semantics, you're deliberately not ignoring the return value with the using (and that's how using(GetDisposable()){} works today).

[MithrilMan]

I agree, but I'm talking about something that should be considered a bug and not a design choice because the legacy using statement allows it.

[lcsondes]

I'd appreciate an official statement either way, ultimately the problem is that a using block takes expressions (which naturally includes discard assignment expressions) but a using statement does not. I can imagine there could be a parsing problem having to deal with the very similarly-looking using Some.Namespace; and that (expression) just so happens to be an expression itself, but nobody has indicated that this was in fact the reason behind this limitation.

[MithrilMan]

I don't think that's the problem because using pattern happens within methods and AFAIK you can't declare a namespace inside a method, in any case I don't expect MS guys could be stopped by this :)
would be nice to have an official position about the issue.

[YairHalberstadt]

Closing as duplicate of championed issue #2235

[YairHalberstadt]

My bad - this isn't an exact duplicate. Moving to discussion.