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
}

[airbreather]

So there is potentially no ambiguity at all.

Can anyone think of a way to get something like A.B to exist simultaneously as both a namespace and an expression in the same context?

From my understanding, it's not that it's impossible to resolve the apparent ambiguity (and even if a usage does happen to be ambiguous somehow, I think there's a general understanding that an error would be fine).

Rather, as I understand it, the issue here is that because a statement at the top of a file of the form using _ = A.B; could be interpreted either way depending on semantic context, parsing it becomes a lot more complex because you can no longer distinguish between the two extremely different possible meanings of this line at the syntax level.

So (again, as I understand it) if this were the kind of feature that would REALLY add a lot of value, then I'm sure the team would be able to overcome the issues and get something that works just perfectly (which is why I imagine this hasn't been outright closed as "rejected"). As the problem it solves is really just a minor inconvenience in the grand scheme of things, however, I'm not surprised that it has taken this long without a resolution.

[jackalvrus]

While I understand and applaud the push to reduce unnecessary ceremony, fixing this would improve my developer experience far more than top-level statements ever will.

[TahirAhmadov]

Probably a non starter, but changing the namespace using to import and alias using to alias, and leaving using to just do IDisposable, would alleviate all these ambiguities, in addition to being somewhat easier to read.

[CyrusNajmabadi]

Yes. That would be a non-starter. That would also introduce its own set of issues as things like import x.y.z; and alias x = y; are already legal in c# today :)

[crozone]

While I understand and applaud the push to reduce unnecessary ceremony, fixing this would improve my developer experience far more than top-level statements ever will.

Agreed, besides being next to useless for experienced developers, top level statements are already an ugly hack and come with a huge list of caveats which need to be considered when programming in that context. I don't think adding yet another caveat to that list of pitfalls will be much of an issue, for a feature that is hugely useful in actual real-life code.

[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?