Can't use C# 8.0 using declaration with a discard

[RayKoopa]

Champion issue: #8606

C# 8.0 adds the possibility to declare using variables without a corresponding using block, discarding the variable as soon as the scope in which it was declared is left.

The official example shows it with assigning the using variable to an actually named variable as you would typically do:

// Pre C# 8.0 code:
static void Main(string[] args)
{
    using (var options = Parse(args))
    {
        if (options["verbose"]) { WriteLine("Logging..."); }
        ...
    } // options disposed here
}

// Becomes:
static void Main(string[] args)
{
    using var options = Parse(args);
    if (options["verbose"]) { WriteLine("Logging..."); }
    ...
} // options disposed here

However, this does not seem to work if I don't actually need the variable being disposed. My use case is a temporary Seek object which remembers the current position in a stream when created, and reverts to that position upon being disposed. It is used like this:

byte[] ReadDataAtFollowingOffset(ExtendedBinaryReader reader)
{
    int offset = reader.ReadInt32();
    int length = reader.ReadInt32();
    using (reader.TemporarySeek(offset, SeekOrigin.Begin))
    {
        return reader.ReadBytes(length);
    }
}

I tried to rewrite this in C# 8.0:

byte[] ReadDataAtFollowingOffset(ExtendedBinaryReader reader)
{
    int offset = reader.ReadInt32();
    int length = reader.ReadInt32();
    using reader.TemporarySeek(offset, SeekOrigin.Begin);
    return reader.ReadBytes(length);
}

However, this yields CS0118 'reader' is a variable but is used like a type. A bit stumped here already, I then tried storing the Seek instance in a discard variable at least:

byte[] ReadDataAtFollowingOffset(ExtendedBinaryReader reader)
{
    int offset = reader.ReadInt32();
    int length = reader.ReadInt32();
    using _ = reader.TemporarySeek(offset, SeekOrigin.Begin);
    return reader.ReadBytes(length);
}

But this now yields CS0246 The type or namespace name '_' could not be found (are you missing a blahblahblah...?). More stumped, I then became even more explicit:

byte[] ReadDataAtFollowingOffset(ExtendedBinaryReader reader)
{
    int offset = reader.ReadInt32();
    int length = reader.ReadInt32();
    using Seek _ = reader.TemporarySeek(offset, SeekOrigin.Begin);
    return reader.ReadBytes(length);
}

While this compiles, it feels very odd to me. Jokes on Visual Studio 2019 trying to break my code now too and forgetting to use using at all:

Is this a known issue, done on purpose, or an oversight in the feature?

[sharwell]

@mavasani for the code fix bug

[mavasani]

We should probably just consider a using variable declaration as an effective read of the underlying variable, so the assigned value is not deemed as unused. I can send a PR for it tomorrow.

[mavasani]

Tagging @chsienki @AlekseyTs and @333fred. The false positive from the IDE unused value assignment analyzer is due to missing IOperation support and hence missing ControlFlowGraph support for using variable declarations #dotnet/roslyn/issues/32100. Analyzer is performing flow analysis on top of CFG to flag assignments whose target is never read or referenced. CFG for this code has a local variable declaration wrapped with an Operation.None and there is no subsequent local reference operation in the CFG. Implementing CFG support for this node would ensure there is an implicitly generated ILocalReferenceOperation for the compiler generated dispose invocation, which would remove the false positive from this analyzer and hence no suggestion to use discard would be offered.

[mavasani]

Actually, the analyzer/code fix to recommend using discard should be fixed in VS2019 Preview4 with
dotnet/roslyn#33036 - the first commit in that PR avoids flagging this case. I will verify it with latest dogfood build tomorrow.

[mavasani]

Confirmed that unused value diagnostic + use discard code fix is offered in VS2019 Preview2 but not in latest VS2019 dogfood builds, and should be fixed in upcoming Preview4 release.

[chsienki]

@RayKoopa the new using declaration feature only works for explicit variable declarations, you can't apply using to arbitrary expressions, even if that expression results in an IDisposable. It is when the declared variable goes out of scope that the object it's referencing is disposed.

Essentially

using (var x = ...) 
{
  x.DoSomething();
}

can be re-written as

using var x = ...
x.DoSomething();

but

using(SomeExpression())
{
}

Can't be directly translated, as there's no declaration in the statement. You can however, assign it to a variable and it'll work, even if you don't use the variable for anything else. As you saw some of the tooling in the previews is a little out of sync with the newest language features at the moment, hence the unused diagnostic in VS, but the compiler will correctly track that it's actually used.

[RayKoopa]

Thanks for letting me know @chsienki! I noticed I can even go as far as

using var _ = ...

to "pseudo" discard the variable here, and it would still compile. That's really sufficient, just wanted to make sure it was done on purpose like this and is not something like an oversight.

[StephenCleary]

Can't be directly translated, as there's no declaration in the statement.

This would be quite useful. I'd love to be able to use using declarations with discards.

[notanaverageman]

There is also the problem of multiple discards. For now the only way is to add more underscores (actually giving different names to the variables as they are not really discards):

using var _ = ...
using var __ = ...
using var ___ = ...
...

[reflectronic]

This could be useful for RAII-style lock acquisition; for example, one would be able to do

void M()
{
	using _ = myLock.Acquire() // rest of scope is protected by lock
    // ...
}

instead of having to implement something like #2451.

[jnm2]

This also makes it painful to use .ConfigureAwait(false) on IAsyncDisposable:

var foo = new Foo(); // Foo : IAsyncDisposable
await using var unused1 = foo.ConfigureAwait(false);

// ...

In order to avoid declaring unused variables, you must go back to a using statement:

var foo = new Foo(); // Foo : IAsyncDisposable
await using (foo.ConfigureAwait(false))
{
   // ...
}

[TehPers]

What about this syntax for discarding the value?

using myLock.Acquire();
// lock-protected code

// Also, don't forget about IAsyncDisposable!
await using myLock.AcquireAsync();

[quinmars]

@TehPers, the problem is that:

using (myLock.Acquire());

is already valid C# code and means something slightly different. Namely dispose the resource right now and not at the end of the outer block.

[yinyue200]

up

[jackalvrus]

Our use case for this is Serilog's PushProperty method. It would be nice if we could write something like:

using _ = LogContext.PushProperty("a", a);
using _ = LogContext.PushProperty("b", b);
using _ = LogContext.PushProperty("c", c);

// the function body

instead of:

using (LogContext.PushProperty("a", a))
using (LogContext.PushProperty("b", b))
using (LogContext.PushProperty("c", c))
{
    // the function body
}

[andre-ss6]

Let's introduce the using_ keyword. Simple 😅

[Charlieface]

I agree, allowing using _ = GetIDisposable(); would be hugely useful.

One option for the top-level statement problem might be to simply disallow them. It's not like anyone uses them in any realistic scenario 😀

Realiztically, we can just disallow _ as a using alias, with a breaking change. It's going to be a very rare person who has an underscore as an alias, whereas our current issue seems to be far more widespread.

The breaking change itself is not going to change the meaning of anyone's code apart from preventing it from compliing, unless they both used top-levels and an underscore alias, presumably vanishingly rare.

[MelGrubb]

Let's introduce the using_ keyword. Simple 😅

Nah, the new keyword should clearly be "notusing"

[aradalvand]

Hopefully the new breaking change warning proposal could allow us to sort this out once and for all. We should either enable:

using GetSomeDisposable();

(which currently, if there are parentheses around the expression, could mean this)
or

using _ = GetSomeDisposable();

(which currently could be a type alias)

The former is actually the ideal one; it would be perfect.

[AlanHauge-Interacoustics]

The former is actually the ideal one; it would be perfect.

I think both should be available, in case the local rules allow unassigned object, and do not force the discard notation for non-used return values.
Perhaps the first one is regarded as a used return value.

[DavidArno]

Perhaps the first one is regarded as a used return value.

I like your thinking. Technically it is used as you say. I prefer the using _ = ... notation, but would be happy with either as both are an improvement on the using junk = ... that I currently have to use.

Agreed, besides being next to useless for experienced developers, top level statements are already an ugly hack...

After 10 months, I've finally stopped laughing at this statement. I love top level statements: they are one of the best features added to the language in recent years. But there again I wrote my first line of code only 42 years ago, so I guess I don't yet qualify as experienced 🤣

[aradalvand]

Perhaps the first one is regarded as a used return value.

What does a "used return value" mean?

[AlanHauge-Interacoustics]

Perhaps the first one is regarded as a used return value.

What does a "used return value" mean?

I mean, it is a warning (maybe from resharper), when you call a method, but do not use the return value for anything
This gives a warning:

something.ToString();

this does not:

string someText = something.ToString();

[Rekkonnect]

Is it really a problem that we have an ambiguity in top-level statements? using having this many meanings is already confusing enough, and seeing a lot of them stacked up in the same indentation level will not be very straight-forward to understand:

using System;
using System.Collections.Generic;

Console.WriteLine("Beginning using");
using MyResource();

Console.WriteLine("Terminating using");

IDisposable MyResource()
{
    return null; // maybe something not null
}

Using the block using statement will surely solve this problem. It will be clearer that the using statement is about consuming and disposing an IDisposable that we do not intend to store anywhere.

Alternatively, if we want a universal solution that also covers top-level statements, I think that indicating that this is a using statement on an expression, we could adopt something like using var. using var will be a special kind of syntax that will be resolved as an unused variable of a disposable resource that we will dispose upon exiting the current scope. The syntax will be something like this:

using var MyResource();
using var x = AnotherResource();

The justification is that uninitialized variable declarations are not allowed in a scope-wide using statement. This using var clearly denotes that an IDisposable expression is being returned and used for disposal, but not stored in any variable.

using var expr; will be an alternative to the hypothetical using _ = expr; which I personally find harder to type and comprehend.

[shand-obs]

Why not simply permit using AllocateMyResouce(); when not at the top level, and require using (AllocateMyResource()) { ... } at the top level? The majority of C# statements in most projects are inside of methods or functions where using namespaces is already not permitted.

[CyrusNajmabadi]

Right. And that's enormously subtle. Making it so that removing/adding those parens entirely changes the semantics around disposal is problematic.

Similarly, using _ = System; is legal code today. So that just leaves using var _ = System; while allowing multiple declarations (and then prohibiting usage of the _ variable).

[RikkiGibson]

Leaving aside using directives entirely: I think the distinction between using (expr); (existing meaning) and using expr; is way too subtle.

It is unfortunate to have to compromise on the ergonomics because of essentially a degenerate case. I can't say whether making a breaking change there would be viable, though.

[AlanHauge-Interacoustics]

Currently, this is valid:

using var unused1 = AllocateMyResource();
using (var unused2 = AllocateMyResource());

Has this subtle difference been a problem?

So the suggested notation does not add any new problems, that are not already there.

[CyrusNajmabadi]

i don't view that as a subtle difference, as that's not an expression, or a parenthesized version of it. Normally, expr and (expr) has the same meaning in the language, but the using version of each would be different.

This is why my preference is to not apply this to the expr forms, but only the var decl forms. I don't see why it wouldn't be good enough to just allow:

using var _ = AllocateResource1();
using var _ = AllocateResource2();
using var _ = AllocateResource3();

Simple, and easy. We just need to make the error here something that is now legal, with discard meaning. Similar to how we made it so that (_, _) => ... stopped being illegal and just meant you must be using the _ as a discard and not as the name of some new variable.

[kasperk81]

making a breaking change there would be viable

it's not too viral https://github.com/search?q=%22using+_+%3D%22+language%3AC%23&type=code.

compiler can continue to treat using _ = before the code starts (CS1529) as using directive, elsewhere it's a using statement?

[murshex]

using _ = MethodReturnsDisposable();

This should work and it’s a shame it doesn’t.

[miyu]

Is there agreement that this should be valid?:

using var _ = SomeDisposable1();
using var _ = SomeDisposable2();

There is debate on terser versions (using _ = X()) and (using X()) but I don't see why that should block the "existing using variable declaration with discarded name" approach from moving forward? Can anyone else see a world where using _ = X() or using X() should be valid but the above shouldn't?

[murshex]

Discards don’t require you to write var. That would be weird.

[Richiban]

I understand the difficulty around top-level statements but, I've got to say, this is a real irritation anywhere an IDisposable is used to define some kind of custom scope-like behaviour. There are loads of these, but the biggest culprit I deal with on a day-to-day basis is even in the BCL, with ILogger<T>.BeginScope.

My code is littered with hundreds of examples like this:

public void M()
{
    using var scope1 = logger.BeginScope("A");
    
    // Do some stuff

    using var scope2 = logger.BeginScope("B");

    // Do some stuff

    using var scope3 = logger.BeginScope("C");

    // Do some more stuff
}

I never use these scope1, scope2 variables but I have to declare them; if I go back to the block-based using I at least don't have to introduce these unused variables but my code becomes more and more indented to the right. It's a bit of a Morton’s Fork.

[MelGrubb]

I get this too. I got in the habit of calling them logSomethingDescriptive. For example, logStart, logRequest, logResponse, and logEnd just to keep them separate, and somewhat self-documenting.

[hez2010]

As for using _ = A.B, I believe there's an existing proposal where we want to make a breaking change to the language that makes _ a keyword instead of an identifier, which will resolve all the issues.

[CyrusNajmabadi]

A concern i have is the ambiguity with using aliases. In other words, using _ = A.B.C; is already legal today. Note that this pattern appears in the wild: grep.app/search?f.lang=C%23&q=using+_+%3D including in places like unity:

Unity-Technologies/FPSSample@6b8b27a/Packages/com.unity.render-pipelines.high-definition/Editor/RenderPipeline/Camera/HDCameraEditor.Handlers.cs#L11-L22

Another example shows this likely being used to shorten generic signatures: reinforced/Reinforced.Tecture@140974b/Aspects/Reinforced.Tecture.Aspects.Orm/Commands/Add/AddExtensions.cs#L798-L799

It feels unlikely that we could break this. So we'd have to accept the same form at top level and inside a method, with the different meanings.

[CyrusNajmabadi]

@sab39 Please open a new discussion then. this discussion is aobut allowing discards. That's something i'm willing to champion. Extending it beyond that, especially with all this extra complexity, all to support something which can be done with this feature isn't something i'm personally interested in.

[sab39]

Sorry, I was going by the original post at the top of this discussion, which only introduces the idea of using a discard as a workaround after the poster was "stumped" by the simple form not working. Might be worth updating the top level post to clarify that the original problem is now considered out of scope of this discussion, to avoid other people having the same confusion?

[jnm2]

@CyrusNajmabadi I think this discussion has to be wider, or else we should switch back to the discard-specific discussion I closed in favor of this existing one. I would like LDM to discuss whether discards remain at the core of this feature.

[CyrusNajmabadi]

The championed issue is literally using with a discard :)

[333fred]

No one will be visually confused by using new SomeType(); or using SomeMethod();.

Unfortunately I'm thinking of one problem that encumbers using expr;, and that is that using (expr); already has a meaning. The existing meaning does cause warning "CS0642 Possible mistaken empty statement."

Indeed. I also disagree with the statement that no one will be confused; I think it will be highly confusing for readers. The using _ = disposable; form is really the only one I think has traction.