Disposal of out parameter discards

[mpolicki]

Motivation

Suppose I have

class C : IDisposable

and some method

int M(int a, out C b)

Sometimes, when I call M, I don't need the value of b. But since b is IDisposable, I can't just use a discard because then b doesn't get disposed of:

var result = x.M(3, out _); // Not good, ignores an IDisposable

Instead, I have to create a temporary variable to take the value of b and call Dispose on it:

var result = x.M(3, out var notNeeded);
notNeeded.Dispose();

But this is noisy and (partially) defeats the purpose of having out parameter discards.

Proposal

If an out parameter is IDisposable and is discarded, automatically call Dispose on it. I.e. rewrite this

var result = x.M(3, out _);

into this

var result = x.M(3, out var notNeeded);
notNeeded.Dispose();

The only downside I can think of is that the behavior of the program might be altered in case the Dispose call has side effects. If this is unacceptable, then I have an alternate proposal.

Alternate proposal

Introduce a mechanism for the programmer to signal that an IDisposable out parameter discard should be disposed of. For example, a new keyword dispose, used in the following way:

var result = x.M(3, dispose out _);

which could get rewritten into:

var result = x.M(3, out var notNeeded);
notNeeded.Dispose();

[CyrusNajmabadi]

Definitely do not like this. If you don't need to use the value, provide an overload (or extension) that does this and just have all your camera call that instead

[jnm2]

There have been a number of times (mostly with SafeHandles from p/invoke calls) that I would have liked to say out using var x, but this has got to be niche.

[mpolicki]

I realize this is niche. However, the more mature a language is, the less big improvements there are to make. Pretty much all that's left are rough edges here and there that increase friction for the programmer. Sure, you could write overloads for the situation I described in the proposal. But then again, every syntactic sugar feature that has been introduced into the language so far could have been worked around somehow.

[CyrusNajmabadi]

However, the more mature a language is, the less big improvements there are to make.

I strongly disagree. There are many large areas of high interest for the team :)

Sure, you could write overloads for the situation I described in the proposal. But then again, every syntactic sugar feature that has been introduced into the language so far could have been worked around somehow.

1. that's tautological given that you called it syntactic sugar :)
2. we provide sugar when we think there is high value to it. i.e. it's something broadly applicable to many.

Providing an entire language feature (which costs many thousands of man hours) to save a tiny group of people from writing a single simple overload just doesn't make sense. We would likely spend more time trying to change the language than the sum total of time saved by everyone using this feature. That's just not an effective use of language resources IMO.

[mpolicki]

@CyrusNajmabadi

Providing an entire language feature (which costs many thousands of man hours) to save a tiny group of people from writing a single simple overload just doesn't make sense.

I admit I have no experience designing or implementing languages, but as far as changes go, this one seems to fall on the simple side of the spectrum.

Also, it's not a single overload, it's an overload for every method that has one IDisposable out parameter. What if a method has n such parameters? You'd have to write (2^n)-1 overloads to cover all possible permutations for just one method (and you wouldn't be able to use var when calling them either).

We would likely spend more time trying to change the language than the sum total of time saved by everyone using this feature. That's just not an effective use of language resources IMO.

Firstly, I have to wonder how you arrived at this estimate.

Secondly, even if it's true that the number of people affected by this are such a tiny minority as you say, I still think there's value in making deterministic disposal of resources more of a first-class citizen, just like using did.

[CyrusNajmabadi]

Also, it's not a single overload, it's an overload for every method that has one IDisposable out parameter.

Which wuld be what? 0.0001% of all methods? It seems super super niche. :-/

[theunrepentantgeek]

I have to wonder how you arrived at this estimate.

Experience. @CyrusNajmabadi works on the C# team. He's experienced first hand just how much work is involved in language changes, even seemingly simple ones like this. His comment of "many thousands of man hours" is almost certainly not hyperbole, but a simple statement of fact.

[mpolicki]

@theunrepentantgeek

Experience. @CyrusNajmabadi works on the C# team. He's experienced first hand just how much work is involved in language changes, even seemingly simple ones like this. His comment of "many thousands of man hours" is almost certainly not hyperbole, but a simple statement of fact.

I'm sure he's able to estimate better than me how much work this would require, but my comment was directed more at his statement about how rarelyIDisposable out parameters need to be discarded. I find that things like that are best answered by data, and I'm wondering if there is any.

It's also worth considering that something that's harder to use might drive people to a different approach, even though the first approach would be a better fit, if only it were easier to use.

[theunrepentantgeek]

how rarely IDisposable out parameters need to be discarded

The only solid data I have is my own experience. My single data point is this: I've never needed it, nor seen it, not in 17 years and ~3 million lines of C# code.

There are people around who have datasets of code from GitHub (and elsewhere) and the ability to run semantic aware queries across them. I'd be interested to see their figures for this.

[HaloFour]

Niche or not, this is a breaking change. I'd be pretty annoyed if I stuck a bunch of values that happened to be IDisposable into a dictionary and all of a sudden the compiler started to dispose them just because I was using TryGetValue and discarded the value.

[mpolicki]

@HaloFour

I'd be pretty annoyed if I stuck a bunch of values that happened to be IDisposable into a dictionary and all of a sudden the compiler started to dispose them just because I was using TryGetValue and discarded the value.

Isn't that what ContainsKey is for?

But also, please see the Alternate proposal section.

[CyrusNajmabadi]

Isn't that what ContainsKey is for?

No.

Even if i grab a value, i may not want to dispose it. This is actually much more common for me. i.e. i have a dictionary that pooled poolable objects. I use those object for some period of time, but only dispose at some much later point in time.

[mpolicki]

@CyrusNajmabadi

Even if i grab a value, i may not want to dispose it.

If you do dictionary.TryGetValue(key, out _), how are you able to use the out parameter value if you're immediately discarding it? The only thing you can get out of that call is the return value, which is the same as what ContainsKey returns.

[jnm2]

@mpolicki I believe TryGetValue was only used as an stand-in for the concept of methods with out parameters in general. I'm very used to discarding and would be surprised if out _ began executing code.

[mpolicki]

@jnm2 I understand if implicit disposing of discards is too much of a breaking change. I do think there should at least be an explicit shorthand way of doing that.

[HaloFour]

There isn't a shorthand way to declare a using scope around an out parameter in general. I think you need to start there before you consider one for discards. There isn't much of an ask for that either because frankly it's weird for an API to return a disposable as an out parameter with the expectation that the consumer dispose of it.

[mpolicki]

@HaloFour
That seems like a good way to generalize, and @jnm2 mentioned needing it as well.
Then

var result = x.M(3, using out var outValue);
// rest of block

could be rewritten as

var result = x.M(3, out var outValue);
using(outValue)
{
// rest of block
}

and

var result = x.M(3, using out _);

could be rewritten as

var result = x.M(3, out var notNeeded);
notNeeded.Dispose();

My only problem with that is the use of the word "using" for the discard case, considering that the semantics of using and discarding something are in opposition, but I guess I can live with that.

[jnm2]

Quick clarification: I didn't mention needing it, but it would make it nicer to work with SafeHandle out parameters in p/invoke and COM interop calls (a niche scenario).

[NN---]

There have been a number of times (mostly with SafeHandles from p/invoke calls) that I would have liked to say out using var x, but this has got to be niche.

It is not niche.
Is there a proposal for out using var ?
I have a lot of P/Invoke code with out parameter due to C functions nature.

[jnm2]

I would have used this feature today for p/invoking https://docs.microsoft.com/en-us/windows/win32/printdocs/openprinter.

Instead of looking like this:

    Winspool.OpenPrinter(printerName, out using var hPrinter, pDefault: IntPtr.Zero).ThrowLastErrorIfFalse();

    using (hPrinter)
    {
        Winspool.StartDocPrinter(hPrinter, Level: 1, new Winspool.DOC_INFO_1 { pDocName = documentName, pDataType = "RAW" }).ThrowLastErrorIfFalse();

        Winspool.StartPagePrinter(hPrinter).ThrowLastErrorIfFalse();
        
        // ...
    }
}

It would have ended up looking like this:

    Winspool.OpenPrinter(printerName, out using var hPrinter, pDefault: IntPtr.Zero).ThrowLastErrorIfFalse();

    Winspool.StartDocPrinter(hPrinter, Level: 1, new Winspool.DOC_INFO_1 { pDocName = documentName, pDataType = "RAW" }).ThrowLastErrorIfFalse();

    Winspool.StartPagePrinter(hPrinter).ThrowLastErrorIfFalse();
    
    // ...
}

[jnm2]

Is there a proposal for out using var ?

@NN--- There is a request now: #3798

[GrabYourPitchforks]

Winspool.OpenPrinter(printerName, out using var hPrinter, pDefault: IntPtr.Zero).ThrowLastErrorIfFalse();

This isn't a typical p/invoke pattern. The typical way of writing a reliable p/invoke - especially p/invokes dealing with safe handles - is to split it into an internal helper function and the private p/invoke function, as shown below.

internal static SafePrinterHandle OpenPrinter(string printerName)
{
    if (!OpenPrinter(printerName, out SafePrinterHandle printerHandle, IntPtr.Zero)) { /* throw */ }
    else { return printerHandle; }
}

[DllImport(...)]
private static extern bool OpenPrinter(...);

This makes the call site(s) look nicer, since they more closely resemble consumption of natural managed object-oriented code.

void SomeCaller()
{
    using var printerHandle = Utility.OpenPrinter("printerName");
    // use 'printerHandle' here
}

Of course you're always free to use different conventions within your app / library. But the pattern I called out above is what the .NET team generally advocates. I don't see how this generally recommended pattern would benefit from the language feature proposed here.

[mpolicki]

The typical way of writing a reliable p/invoke - especially p/invokes dealing with safe handles - is to split it into an internal helper function and the private p/invoke function

This isn't always necessary, for example if you have HRESULT-returning functions and declare them with PreserveSig = false.

In general, using out var/using out _ would be useful when you have to return more than one value, one or more of which are disposable.