Support for "using" in function parameters

[Acerby]

I would like to propose support for the use of temporary proxy wrappers for parameters passed to functions. These proxies would then disposed of immediately AFTER the function had returned. This automatic disposal would be indicated by the inclusion of "using" keyword, as illustrated in the following examples:

Example 1:

if(myOldMethod(using new myProxy(newInteface)))
{
    // proxy has been disposed of here
}
else
{
    // and here
}

Example 2:
// supporting "ref" like parameters to async methods

async Task Main()
{
     
    var c = new oldClass();
    var s1 = "myString";
    var s2 = "myString";

    // the old way
    var w=Wrapper.For(s1, ns => s1=ns);
    var r=await c.MyOldFunction(w);
    w.Dispose();
    if(r)
    {
         s1.Dump();
    }
    
    // the new slightly cleaner syntax
    if(await c.MyOldFunction(using Wrapper.For(s2, ns => s2=ns)))
    {
        s2.Dump();
    }	
     
}

interface IOldInterface
{
     string TheValue {get;set;}
}
class Wrapper : IOldInterface, IDisposable
{
    Action<string> _onClose;
    public static Wrapper For(string a,Action<string> onClose)
    {
        return new Wrapper { TheValue = a,_onClose=onClose };
    }
    public string TheValue {get;set;}
    public void Dispose()
   {
        _onClose(TheValue);
    }
}

class oldClass
{
    public async Task<bool> MyOldFunction(IOldInterface ov)	
    {
        await Task.Delay(100);
        ov.TheValue=ov.TheValue + "!!!";
        return true;
    }
}

[Tom01098]

This seems quite nifty, but I think that the one who created the object should be the one who disposes of it, otherwise this could cause a lot of confusion and obscure bugs. I also can't think of a situation where a method can guarantee no one will want to use the object after it's finished executing.

[canton7]

Personally, I'm strongly against adding syntactic sugar which is:

1. Rarely used
2. Only saves a few characters
3. Doesn't massively aid clarity

One the one side, you have the number of man-hours that you waste worldwide from people seeing this syntax that they've never seen before, and having to figure out / look up what it means. On the other side, you have the reduced time to type a few characters, and potentially reduced time grokking what the code does if you're familiar with the syntax.

I don't think this meets that bar at all. It's only 7 characters shorter, it's going to be very rarely used, and I think it reduces clarity.

---

Also, the behaviour around Task-returning methods is not obvious. Take for example

var foo = await Foo(using GetSomething());

Does the result of GetSomething get disposed when Foo returns, or when the await completes? If it's the former, that's a footgun. If it's the latter, that falls down quite quickly.

Is the result of GetSomething disposed after the await task line here?

var task = Foo(using GetSomething());
await task;

What about this? When is the result of GetSomething disposed now?

public Task Bar() => Foo(using GetSomething());

await Bar();

[Joe4evr]

On the other side, you have the reduced time to type a few characters

Which is likely on the scale of milliseconds at most considering that the using snippet can type most of those characters for you instantaneously.

[huoyaoyuan]

If I'm correct, the using proposal is actually saving a bit more for some situations:

TResult result;
using (var r = new Resource())
    result = DoSomething(r);
DoAnother(result);

becomes:

DoAnother(DoSomething(using new Resource());

But this only benifits if you need to dispose the resource as eager as possible, which is uncommon. Otherwise, you can dispose the resource after everything on the result are done.