unusing statements

[Yen]

Every so often, there is a new issue opened here for RAII in C#. I am a fan of C++ and have also thought about similar things being added to C#, however it is clear from the responses to previous issues that although desired by many developers, RAII syntax in the traditional form of destructible types is not the solution to explicit resource management in C#. I will instead propose additions to the "using statement" syntax that should help solve some of the problems where RAII helps, while being able to still use IDisposable as its core.

While writing C# that interfaces with lower-level C APIs, it's often very difficult to write exception-safe code. The "ideal" way to interface with unmanaged resources in C# would be to wrap all resource creation in managed classes capable of using primitive such as GCHandle to correctly manage their lifetimes and dependencies. The problem is this is very verbose when you start dealing with APIs with complex dependency graphs such as Vulkan, where to do everything correctly would require very complex reference counting behind the scenes to ensure that finalizers are run in the correct order while keeping weak references to parents that are needed for API operations and destruction. The compromise that is often made is to instead model unmanaged resources as IDisposable instances and take care of clean up code manually. Unfortunately, although this may seem as if you were writing something similar to C at this point, and acceptable for lower-level code, the presence of exceptions in C# makes this code inherently exception unsafe, something which really shouldn't be the case.

When trying to write exception safe code, RAII is often shown as a solution in many cases, but more specifically the ability to tie lifetimes of variables to a scope is the important part. Thankfully in C# we have this to a degree in the form of "using statements" and IDisposable. As of right now however, there are some shortcomings.

Consider the following example:

bool TryCreateFoo(out Foo foo)
{
    if (!TryCreateBar(out var bar))
    {
        foo = null;
        return false;
    }

    if (!TryCreateBaz(out var baz))
    {
        bar.Dispose();
        foo = null;
        return false;
    }

    if (!TryCreateQux(out var qux))
    {
        baz.Dispose();
        bar.Dispose();
        foo = null;
        return false;
    }

    foo = new Foo(bar, baz, qux);
    return true;
}

Here we are using a try-pattern function to create some resource which has explicit resource management and which requires a number of dependencies which also require explicit resource management. The issue is that by default, we need to delete these manually. When working with more complex APIs, this can get quite out of hand. For example I have Vulkan related objects that can have 10s of variables that need to be cleaned up in the case of failure. It should be noted that we could argue that an exception based control flow instead of the try-pattern would be less verbose, but we get memory leaks here and the only way to do so while being exception safe is to have a separate try/catch/finally block for each resource we allocate.

If we tried to use using statements in out variables as suggested in #3798 or #2894 to solve this problem instead, we might end up with a somewhat cleaner solution that is most importantly exception safe, but still has a fatal problem:

bool TryCreateFoo(out Foo foo)
{
    if (!TryCreateBar(out using var bar))
    {
        foo = null;
        return false;
    }

    if (!TryCreateBaz(out using var baz))
    {
        foo = null;
        return false;
    }

    if (!TryCreateQux(out using var qux))
    {
        foo = null;
        return false;
    }

    foo = new Foo(bar, baz, qux);
    return true;
}

Note I am using this "using on out var" proposed syntax from the above discussions as it makes this very concise, but the same outcome is possible in a more verbose way with the current syntax.

The issue is this of course does not work, as we are constructing Foo with variables that will be disposed once the function returns and the scope is exited. Aside from that, without needing to recreate an entire new model for RAII object types, we have managed to make exception safe resources at the very least at a function level while still utilizing the IDisposable pattern. As this is an ideal syntax, I would propose an addition that makes this work in practice.

The addition would be the ability to "undo" a using declaration such that the variable is no longer disposed if the scope is exited after this "undo" has occurred. See the following tentative syntax:

bool TryCreateFoo(out Foo foo)
{
    if (!TryCreateBar(out using var bar))
    {
        foo = null;
        return false;
    }

    if (!TryCreateBaz(out using var baz))
    {
        foo = null;
        return false;
    }

    if (!TryCreateQux(out using var qux))
    {
        foo = null;
        return false;
    }

    unusing qux;
    unusing baz;
    unusing bar;
    foo = new Foo(bar, baz, qux);
    return true;
}

Here we introduce "unusing statements" as a way to tell the compiler that after this point, the variable should no longer be automatically disposed on scope exit. This small feature allows us to write full exception safe code like above while dealing with resources that depend on IDisposable for their lifetime management. I understand that microsofts own libraries moved away from having resources depend on IDisposable with WPF for instance, but there are many times where this is often a lot of work for what could be easily managed at the function level like above. The unusing keyword here is obviously quite silly (not that I can think of anything better), but the functionality it provides would make a lot of code that I have at the moment considerably easier to feel safe writing. With a focus on AOT (the reason I am writing this Vulkan related code rather than using C++ as I normally would), I feel C# could use some better tools for writing exception safe code when dealing with manual resources rather than pushing it to the side and considering a bad experience for "low level" or "implementation detail" code to be acceptable.

With this in mind, I would consider what this feature might allow if it was to be implemented in full. Specifically, that the nature of a "using declaration" an "unusing declaration" might become more general. For example, we might allow using x; as a standalone syntax to start "using" a variable in a scope. As such writing code such a using x; unusing x; using x; unusing x; would become legal and might have its uses, but is more to show that a generalised form of the syntax is possible. Naturally "using" a variable that is currently "used", or "unusing" a variable that isn't, would be a compile time error as this should be fully detectable and required for codegen to make sense.

Edit: I have redacted the final section of my initial post as I now believe this work can be done by analyzers and is unrelated to the addition of "unnusing statements" and its corresponding syntax.

I appreciate the time and have other alternative syntax that might work for this, but this was the minimal product that I felt was needed to make the code enjoyable to write. Just for fun however, I will share how a much more complete solution might help for more explicit resource management:

class Foo
{
    // note here the using modifier used as a argument to a method, in this case as an argument to the constructor.
    // this does not change anything about the class and is purely a modifier for the argument.
    // having this using modifier tells the compiler that the argument passed in must not be "used" by the caller, that is,
    // it cannot be part of a using statement.
    public Foo(using Bar bar, using Baz baz, using Qux qux) // ...
}

bool TryCreateFoo(out Foo foo)
{
    if (!TryCreateBar(out using var bar)) // ...
    if (!TryCreateBaz(out using var baz)) // ...
    if (!TryCreateQux(out using var qux)) // ...

    // this would compile as we are unusing the variables before calling the constructor
    unusing qux;
    unusing baz;
    unusing bar;
    foo = new Foo(bar, baz, qux);
    //

    // this would not compile as the variables are being "used" in the scope, and
    // the arguments to the constructor have using modifiers
    foo = new Foo(bar, baz, qux);
    //

    // an alternative syntax that might be useful in the situation where we allow this
    // using modifier to be used arguments, shorthand for the first example
    foo = new Foo(unusing bar, unusing baz, unusing qux);
    //
    
    return true;
}

This more complete syntax with "using modifiers" for function arguments would stop issues with IDisposable that occur even now where people pass in variables that are part of a using statement, and end up with disposed objects in their data structures. I feel if this is at all interesting it should probably be its own issue, but I have included it here for now as it could also be seen as helping to solve the same problem.

[HaloFour]

I'm personally not a fan of the concept of taking what is declared as a resource to be disposed and having a language feature that toggles that off and on. It makes it more difficult to read the code and understand what it's expected to do as now you have to internalize the entire method body. I'd much prefer a resource wrapper that you could use around the resource that could be used to control disposing and could be disabled.

It's not free, but one tactic I've used to achieve similar is through a ResourceBuilder-like class, where you can create and register the temporary resources intended to be used to build the final resource. If you build the final resource through the resource builder it relinquishes ownership of all of the temporary resources, but if, for whatever reason, you don't build that final resource, then all of the temporary resources would then be disposed. Something like this:

using (var builder = new ResourceBuilder()) {
    var bar = builder.Using(new Bar());
    var baz = builder.Using(new Baz());
    var qux = builder.Using(new Qux());

    return builder.Build(() => new Foo(bar, baz, qux));    
}

[CyrusNajmabadi]

Generally speaking, we dont' add features just because people have distaste for an existing feature that exists to solve teh very case the user is trying to solve.

'goto' is a first class feature in our language and should be used when appropriate (like in this sort of situation).

[Yen]

Right, so i'm saying: refactor that to no longer be the case. Make it so that you have simple objects to define youe graph. Create the graph trivially, and then have that managed by some owner (which can properly dispose it if nececessary). once created, then do an initialization pass (which can fail with exceptions). If it fails, it gets cleaned up. After that point your graph is properly created, initialized, and owned. Then you can do whatever operations you want on it, also having it be cleaned up if anything throws.

You are correct of course. I can restructure my code to have a an object or object graph where by it can exist in an invalid state and I can have logic in my dispose functions to handle this where needed. Unfortunately I don't want my use case to have objects with invalid states when I can instead guarantee their construction without the need for exceptional control flow in basic situations like someone's GPU not supporting the right colour space. The pattern for my code is how I write this in any other systems language, and I can make that work in C#. It is however painful at some parts, and this is one of them.

If the stance of the C# team is that this is not a valid way to want to write code, then so be it. But if not, then I would prefer this to not continue to be a discussion of different, less than ideal ways to write the code I have presented above.

[iam3yal]

@Yen You are giving solutions that absolutely work in Rust, C++ or any other system programming and yet you're essentially saying it's my way or the high way, this is not how things work, you insist that your solution is better even though the code I posted is pretty close to what you're proposing.

[Yen]

@iam3yal I appreciate the suggestions, but I have outlined how the code you have suggested are not general solutions, but solutions to my small that in most cases don't actually address the issue. Your samples will not work with more complex code such as flow control mid function where a language addition tied to the scope does. I also want to make it clear that I am not suggesting C# adopt anything specific that C++ or Rust has, that is not my goal. I am aware that C# uses different patterns (more specifically IDisposable over RAII) and would like to achieve the same result using C#s patterns. The additions I suggest allow more flexibility to IDisposable to allow one to write code that is closer to something I would write in C++ yes. But in C++ I write it this way vs the other 20 ways discussed here that would also be valid C++, because that is the most concise way to express the problem. As far as I am concerned, this would also be the best way to write this in C# if it were possible, which is why I am here.

If it is, as it seems, that my opinion differs to others here in what would be the idea way to write these types of functions, then that is fine, and this feature would not be implemented. I am aware I can put explicit try/catch over all of my code and handle exceptions manually, that doesn't help.

[iam3yal]

@Yen The code I posted might not work for you but then it's based on the examples you provided if your examples aren't similar to what you're dealing with then that's something you should improve, however the pattern I suggested is actually a general solution to the problem regardless to how complex the code is, I think we have different definitions for what general solution really means.

[iam3yal]

Can't you just continue to use the same TryXXX pattern you're already using and flat it like this? also you don't need to set foo to null in every branch.

bool TryCreateFoo(out Foo? foo)
{
    foo = null;
    
    if (!TryCreateBar(out var bar))
    {
        return false;
    }
    
    if (!TrySomeFunctionsThatMayThrow() || !TryCreateBaz(out var baz))
    {
        bar.Dispose();
        
        return false;
    }
    
    if (!TrySomeFunctionsThatMayThrow() || !TryCreateQux(out var qux))
    {
        bar.Dispose();
        baz.Dispose();
        
        return false;
    }
    
    if (!TrySomeFunctionsThatMayThrow())
    {
        bar.Dispose();
        baz.Dispose();
        qux.Dispose();
        
        return false;
    }
    
    foo = new Foo(bar, baz, qux);
    
    return true;
}

bool TrySomeFunctionsThatMayThrow()
{
    try
    {
        SomeFunctionsThatMayThrow();
            
        return true;
    }
    catch
    {
        return false;
    }
}

[Yen]

I apologise for the confusion, I was not referring to the program main, but the main function as in not a standalone function used to wrap exception control flow, but the primary function in the examples given. As for providing the same code in other languages, this is of course possible as I have referred to C++ and Rust several times without providing examples to make it easier to understand for those not familiar with languages that implement an RAII resource model. I refrain from doing so however as I do not want to make C# into C++ or Rust, I was merely referencing them as languages that have solved the problem I have with their own solutions. I don't want to take their solutions, I want a solution designed to best fit C# and the existing language features. This is why I have proposed something as an extension to the IDisposable instead.

If it is still of interest, you can of course look at RAII in C++ or the more simple form in Rust. You will note that the outcome here looks quite similar to if all variables in C# were implicitly in using declarations. There have been some requests for this kind of model in C#, but it is not what I am looking for today. The important bit is that despite looking like RAII and using declarations result in the same thing, a using declaration lacks the final ability to "move" a value such that it's no longer disposed. Without this, the whole resource management that RAII provides does not function. What I am proposing is to take the existing using declaration model in C#, something that in many ways is the same as RAII, and add extra functionality to allow us to do the same things RAII does in situations where it makes sense. As for where it makes sense, since the functionality is similar to RAII in these other languages, I think you will find the arguments for RAII fit the same here.

[HaloFour]

You're not asking for RAII, though. You're asking for mechanisms to circumvent RAII by making destruction conditional. IIRC, in C++, that can only be accomplished through helper types like smart pointers. Rust may have something more than that, but Rust also has a very sophisticated ownership model that is far beyond what C# intends to offer.

The team had explored destructible types at one point, and move semantics to go with it, but I don't believe it was considered worth the complexity. Now that ref structs support using via duck typing, I don't know that there is all that much interest anymore. The lifetime scoping of types seem much more focused on using ref types safely.

[Yen]

Yes, I am not asking for RAII. That is why I have refrained from referring to what I want as such, and from giving example of "look how C++ does it". What I want is control over the using statement, something that is C# specific. I don't want destructible types as I prefaced in the very first post.

As far as how Rust and C++ achieve their functionality.

You're asking for mechanisms to circumvent RAII by making destruction conditional. IIRC, in C++, that can only be accomplished through helper types like smart pointers. Rust may have something more than that, but Rust also has a very sophisticated ownership model that is far beyond what C# intends to offer.

In both C++ and Rust, the way this is handled is not related to their ownership entirely. Their ownership model allows them to conditionally destruct variables. In the case of both C++ and Rust, this is done by moving the value somewhere else. In the case of C#, I don't want destructible types as its far out of the scope of what I am asking for. What I want is only the conditional deconstruction part that destructible types often requires to make work in some form (moving a value out means it's no longer deconstructed as it would be in something like #6611, #6612). I don't want destructible types though so the concept of "moving" values means nothing here, what I want is just the single feature that they happen to also have which is conditional destruction. It's clear that there is a bit of a misunderstanding as to how destructible types and RAII are implemented in other languages, so for the sake of simplicity as I preferred it before, it might be best to not try and compare what's going on here to how they are implemented in other languages. After all, I don't want C# to be C++. I just want my using statements to be more flexible.

[iam3yal]

apologise for the confusion, I was not referring to the program main, but the main function as in not a standalone function used to wrap exception control flow, but the primary function in the examples given.

ahh gotcha.

As for providing the same code in other languages, this is of course possible as I have referred to C++ and Rust several times without providing examples to make it easier to understand for those not familiar with languages that implement an RAII resource model.

Most people that interest in language design program in multiple languages not only in C# and we understand the RAII model perfectly well but more importantly the LDT certainly understand it and it was discussed here plenty of times.

I was merely referencing them as languages that have solved the problem I have with their own solutions. I don't want to take their solutions

Showing how you can express the same thing in other languages more elegantly can be the justification to your proposal and you might convince someone on the LDT that something needs to be done. not all features that exists in one language should carry over to another language but there is nothing wrong with being inspired by features of other languages and base your ideas on top of that as long as the language doesn't provide the necessary constructs to deal with the problem elegantly and it's worth the costs.

I want a solution designed to best fit C# and the existing language features. This is why I have proposed something as an extension to the IDisposable instead.

I know but then you provided examples that may or might not be similar to the code your dealing with that don't do you any favours and it might not be to your liking but there are patterns within the language that you can use and follow to not only simplify the code but are certainly reasonable to use.

If it is still of interest, you can of course look at RAII in C++ or the more simple form in Rust. You will note that the outcome here looks quite similar to if all variables in C# were implicitly in using declarations. There have been some requests for this kind of model in C#, but it is not what I am looking for today. The important bit is that despite looking like RAII and using declarations result in the same thing, a using declaration lacks the final ability to "move" a value such that it's no longer disposed. Without this, the whole resource management that RAII provides does not function. What I am proposing is to take the existing using declaration model in C#, something that in many ways is the same as RAII, and add extra functionality to allow us to do the same things RAII does in situations where it makes sense. As for where it makes sense, since the functionality is similar to RAII in these other languages, I think you will find the arguments for RAII fit the same here.

Fair enough, I'm not arguing against RAII in general or your proposed solution I just think that you can refine the proposal to show real examples and how your proposed solution can actually make that code more readable and elegant. Ultimately, it's not me that you need to convince but the LDT I'm here to provide my honest opinion about it. :)

[Yen]

Fair enough, I'm not arguing against RAII in general or your proposed solution I just think that you can refine the proposal to show real examples and how your proposed solution can actually make that code more readable and elegant. Ultimately, it's not me that you need to convince but the LDT I'm here to provide my honest opinion about it. :)

Thank you for taking the time to comment, it is necessary I know. As far as what I want, I think looking at what RAII solves in the languages that decide to use them might be an approach to explain how I would like to be able to express certain C# code, as such I will do so in C++ as a reference:

std::optional<Foo> TryCreateFoo()
{
    auto bar = TryCreateBar();
    if (!bar)
    {
        return std::nullopt;
    }

    SomeFunctionsThatMayThrow();

    auto baz = TryCreateBaz();
    if (!baz)
    {
        return std::nullopt;
    }
    
    SomeFunctionsThatMayThrow();

    auto qux = TryCreateQux();
    if (!qux)
    {
        return std::nullopt;
    }
    
    SomeFunctionsThatMayThrow();

    return Foo(std::move(*bar), std::move(*baz), std::move(*qux));
}

Here we can see a modern C++ approach to the problem using RAII to model resources and tie their lifetimes to the stack (I would associate this with a using declaration in C#). This is naturally all exception safe, as if an exception is thrown, the variables have their destructors invoked and all is good. What C++ then gives us is the ability to "move" the value into the argument to the Foo constructor, which is something that I don't to replicate as naturally this feature is a lot bigger than this and something far out of scope for this conversation. What I instead want to look at is what that move is doing, which is in essence, stopping the value from being destroyed (in reality in C++ the value is being destroyed, but its empty, however in rust proper moving doesn't even invoke a drop and is arguably a better implementation of the model as a whole). What I want is to replace this behaviour with IDisposable, that is be able to have my variables tied to the scope with using declarations as we can already do, but instead of going down the path of trying to implement move semantics into C#, just add the ability to perform the final step and stop the variable from being disposed. That is all in essence what the "unusing statement" does, and as a result, it lets us get this C++/Rust RAII style, super robust, exception safe control flow.

I also want to add that having using x; and unusing x; as standalone, full flexible statements, gives us the ability to model control flow that isn't very easy to reason about using other methods. For example:

bool TryCreateFoo(out Foo foo)
{
    if (!TryCreateBar(out using var bar))
    {
        foo = null;
        return false;
    }

    SomeFunctionsThatMayThrow();

    if (!TryCreateBaz(out using var baz))
    {
        foo = null;
        return false;
    }

    SomeFunctionsThatMayThrow();

    if (!TryCreateQux(out using var qux))
    {
        foo = null;
        return false;
    }

    SomeFunctionsThatMayThrow();

    unusing qux;
    unusing baz;
    unusing bar;
    if (TryCreateFooA(bar, baz, qux, out foo))
    {
        return true;
    }
    using bar;
    using baz;
    using qux;

    SomeFunctionsThatMayThrow();
    SomeFunctionsThatMayThrow();
    SomeFunctionsThatMayThrow();

    unusing qux;
    unusing baz;
    unusing bar;
    if (TryCreateFooB(bar, baz, qux, out foo))
    {
        return true;
    }
    using bar;
    using baz;
    using qux;

    return false;
}

Here we are trying to use one method to create foo, but potentially failing. We can then use the using x; statements to return to a exception safe form, and continue on with our function knowing all is well. Yes this is weirdly verbose, and a lot of that is down to being manual resource management to a degree, but it is manual resource management that properly works in the confines of an exception capable environment like dotnet. This specific pattern I actually run into myself where I am trying to create renderers for a window, and pass in my ideally "used" IDisposable window objects to a function that will first try and create the window using vulkan, but if it fails, does some more work before falling back to a GDI based solution. Giving explicit control over how using blocks work lets us model stuff like this in a way that would be difficult to do even in C++ (you can't reuse something you moved, even if you didnt end up keeping it, so doing this is not as simple).

[CyrusNajmabadi]

What about:

    bool TryCreateFoo(out Foo foo)
    {
        Bar? bar = null;
        Baz? baz = null;
        Quux? quux = null;

        var success = false;
        try
        {
            success =
                TryCreateBar(out bar) &&
                TryCreateBaz(out baz) &&
                TryCreateQuux(out quux);
            if (!success)
                return false;

            foo = new Foo(bar, baz, quux);
            return true;
        }
        finally
        {
            if (!success)
            {
                bar?.Dispose();
                baz?.Dispose();
                quux?.Dispose();
            }
        }
    }

?

[CyrusNajmabadi]

Now, if you fail to create anything (either for some non-exceptional reason, or for an exceptional reason), you clean things up in the finally. It's a simple pattern, and easy to augment.

[Yen]

Yes, although in my example we have exception throwing code between create calls. We can come up with different scenarios that are not quite as bad sure, but it doesn't address the issue.

[CyrusNajmabadi]

Yes, although in my example we have exception throwing code between create calls. We can come up with different scenarios that are not quite as bad sure, but it doesn't address the issue.

It does though. As i mentioned, if you separate out concerns, then you should be able to do this in C# without trouble.

[Yen]

It does though. As i mentioned, if you separate out concerns, then you should be able to do this in C# without trouble.

Separating out concerns in this context would require, at some point, an explicit try/catch over every function that could throw, and then bubbling that back up to the point where I have to explicitly handle it. I am aware of course that I can do this. This however leaves me with try/catch blocks all over my functions, which I would very much like to avoid as I would rather just let exceptions throw and not have to worry about handling every possible point it can happen. Using try/catch/finally is the requirement, even if I separate it out, to make this work. It is also how using statements work, so naturally they can solve the problem in a more concise way in the same way they can be used already for scoped blocks that throw exceptions. All I am asking is for the ability to adjust the lifetime of these blocks, and potentially exit out of them, and I hope I have shown how this can make certain patterns of code both safer and less verbose at the same time.

[CyrusNajmabadi]

Separating out concerns in this context would require, at some point, an explicit try/catch over every function that could throw, and then bubbling that back up to the point 

It would not. You can still have a top level disposable that cleans all the resources off an exception happens

[ufcpp]

Isn't what we really need destructible types and move semantics?
see #121 dotnet/roslyn#161

[HaloFour]

I do believe OP is looking for move semantics, although applied to IDisposable types. I would prefer that over a generic unusing.

[Yen]

I do not necessarily want move semantics, although it would solve the problem yes. If making a move x expression that basically does the same thing as this unusing x; statement, I am happy to focus on that instead. Moving as a concept has already been proposed in #6612 and I didn't want to replicate this, but doing so specifically for IDisposable as you have outlined might be a good compromise. I have not had time to consider the idea fully, but I am well aware that move semantics can become very fiddly in their implementation around the edge cases (you can see how much work C++ has had to put in to deal with them). If a minimal version can be designed to work with just IDisposable, that might look something like this instead:

bool TryCreateFoo(out Foo foo)
{
    if (!TryCreateBar(out using var bar))
    {
        foo = null;
        return false;
    }

    if (!TryCreateBaz(out using var baz))
    {
        foo = null;
        return false;
    }

    if (!TryCreateQux(out using var qux))
    {
        foo = null;
        return false;
    }

    foo = new Foo(move bar, move baz, move qux);
    return true;
}

Naturally this is gives me warm feelings coming from C++, but I feel like I still worry that C# would not be able to handle the edge cases to the degree that we don't instead benefit more from creating a more general syntax.

For example, if I "move" a value into a try-style function, which fails, how would I get the variable to be back in my scope and disposed properly if I return later? In C++ this wouldn't happen as once you have moved something, it would be cleaned up either way. To do this cleaning up inside of the function I would need a way to "using" my arguments as they come in, totally possible, but it starts to grow the feature. This is just the first scenario, but I feel like if you want to make move work, you need to handle all of these possibilities else it's not really worth it. Having an explicit using x; and unusing x; allows a developer to model any of these strange possibilities as they come up, and ideally, having the move syntax also as a way to invoke unusing x; before the expression its used would be an extra nicety for the common use case.

I am all for full move semantics of IDisposable however if that is something the team might consider, it's probably the most complete way to solve the problem, just a lot more work. :)

[Yen]

I have implemented a pattern I am now using in place of manual management inspired by @HaloFour ResourceBuilder. I am going to post some large code samples as it was suggested to show the problem in practice:

/// <summary>
/// Performs some final checks to make sure our backend can render to the surface and has access to the formats and present modes it wants.
/// </summary>
private static bool _tryCreate(VulkanGraphicsBackend graphicsBackend, VkSurfaceKHR.Disposable surface, [MaybeNullWhen(false)] out VulkanGraphicsPresentableSurface presentableSurface)
{
    using var ds = new DisposableScope();
    ds.Using(surface);

    // check our physical device supports the surface
    if (!graphicsBackend.Instance.GetPhysicalDeviceSurfaceSupportKHR(graphicsBackend.Device.PhysicalDevice, (uint)graphicsBackend.QueueFamilyIndex, surface, out var surfaceSupported))
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Failed to check surface support.", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = null;
        return false;
    }
    if (!surfaceSupported)
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Surface not supported.", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = null;
        return false;
    }

    // check we support our desired surface format
    if (!graphicsBackend.Instance.GetPhysicalDeviceSurfaceFormatsKHR(graphicsBackend.Device.PhysicalDevice, surface, out var surfaceFormats))
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Failed to get surface formats.", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = null;
        return false;
    }
    VkSurfaceFormatKHR? surfaceFormat = null;
    foreach (var acceptedSurfaceFormat in AcceptedSurfaceFormats)
    {
        if (surfaceFormats.Any(f => f.Format == acceptedSurfaceFormat.Format && f.ColorSpace == acceptedSurfaceFormat.ColorSpace))
        {
            surfaceFormat = acceptedSurfaceFormat;
            break;
        }
    }
    if (surfaceFormat == null)
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Surface format not supported.", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = null;
        return false;
    }

    // check we support our desired present mode
    if (!graphicsBackend.Instance.GetPhysicalDeviceSurfacePresentModesKHR(graphicsBackend.Device.PhysicalDevice, surface, out var presentModes))
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Failed to get surface present modes.", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = null;
        return false;
    }
    if (!presentModes.Contains(PresentMode))
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Present mode not supported.", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = null;
        return false;
    }

    // create the render pass
    var renderPassCreateInfo = new VkRenderPassCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO,
        Attachments =
        [
            new VkAttachmentDescription
                {
                    Format = surfaceFormat.Value.Format,
                    Samples = VkSampleCountFlags.VK_SAMPLE_COUNT_1_BIT,
                    LoadOp = VkAttachmentLoadOp.VK_ATTACHMENT_LOAD_OP_CLEAR,
                    StoreOp = VkAttachmentStoreOp.VK_ATTACHMENT_STORE_OP_STORE,
                    StencilLoadOp = VkAttachmentLoadOp.VK_ATTACHMENT_LOAD_OP_DONT_CARE,
                    StencilStoreOp = VkAttachmentStoreOp.VK_ATTACHMENT_STORE_OP_DONT_CARE,
                    InitialLayout = VkImageLayout.VK_IMAGE_LAYOUT_UNDEFINED,
                    FinalLayout = VkImageLayout.VK_IMAGE_LAYOUT_PRESENT_SRC_KHR,
                },
            ],
        Subpasses =
        [
            new VkSubpassDescriptionManaged
                {
                    PipelineBindPoint = VkPipelineBindPoint.VK_PIPELINE_BIND_POINT_GRAPHICS,
                    ColorAttachments =
                    [
                        new VkAttachmentReference
                        {
                            Attachment = 0,
                            Layout = VkImageLayout.VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL,
                        },
                    ],
                },
            ],
        Dependencies =
        [
            new VkSubpassDependency
                {
                    SrcSubpass = VulkanConstants.VK_SUBPASS_EXTERNAL,
                    DstSubpass = 0,
                    SrcStageMask = VkPipelineStageFlags.VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
                    SrcAccessMask = 0,
                    DstStageMask = VkPipelineStageFlags.VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
                    DstAccessMask = VkAccessFlags.VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
                },
            ],
    };
    var renderPassCreateResult = graphicsBackend.Device.CreateRenderPass(renderPassCreateInfo, out var renderPass);
    if (renderPassCreateResult != VkResult.VK_SUCCESS)
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Failed to create render pass: {renderPassCreateResult}", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = default;
        return false;
    }
    ds.Using(renderPass);

    // create the pipeline layout
    var pipelineLayoutCreateInfo = new VkPipelineLayoutCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_LAYOUT_CREATE_INFO,
        PushConstantRanges =
        [
            new VkPushConstantRange
                {
                    StageFlags = VkShaderStageFlags.VK_SHADER_STAGE_VERTEX_BIT,
                    Offset = 0,
                    Size = (uint)Marshal.SizeOf<VulkanGraphicsBasicPushConstants>(),
                },
            ]
    };
    var pipelineLayoutCreateResult = graphicsBackend.Device.CreatePipelineLayout(pipelineLayoutCreateInfo, out var pipelineLayout);
    if (pipelineLayoutCreateResult != VkResult.VK_SUCCESS)
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Failed to create pipeline layout: {pipelineLayoutCreateResult}", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = default;
        return false;
    }
    ds.Using(pipelineLayout);

    // create the vertex shader module
    var vertexShaderModuleCreateResult = graphicsBackend.Device.CreateShaderModule(new()
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO,
        Code = VulkanGraphicsEmbeddedShaders.GetSpirvCode("basic.vert")
    }, out var vertexShaderModule);
    if (vertexShaderModuleCreateResult != VkResult.VK_SUCCESS)
    {
        Debug.WriteLine("Failed to create vulkan presentable surface. Failed to create vertex shader module", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = default;
        return false;
    }
    ds.Using(vertexShaderModule);

    // create the fragment shader module
    var fragmentShaderModuleCreateResult = graphicsBackend.Device.CreateShaderModule(new()
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO,
        Code = VulkanGraphicsEmbeddedShaders.GetSpirvCode("basic.frag")
    }, out var fragmentShaderModule);
    if (fragmentShaderModuleCreateResult != VkResult.VK_SUCCESS)
    {
        Debug.WriteLine("Failed to create vulkan presentable surface. Failed to create fragment shader module", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = default;
        return false;
    }
    ds.Using(fragmentShaderModule);

    // we need to take in our `VulkanGraphicsBasicVertex`
    var pipelineVertexInputStateCreateInfo = new VkPipelineVertexInputStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO,
        VertexBindingDescriptions = [VulkanGraphicsBasicVertex.MakeVertexInputBindingDescription(0, VkVertexInputRate.VK_VERTEX_INPUT_RATE_VERTEX)],
        VertexAttributeDescriptions = VulkanGraphicsBasicVertex.MakeVertexInputAttributeDescriptions(0),
    };

    // we only need to render triangle lists
    var pipelineInputAssemblyStateCreateInfo = new VkPipelineInputAssemblyStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_INPUT_ASSEMBLY_STATE_CREATE_INFO,
        Topology = VkPrimitiveTopology.VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST,
    };

    // we dont perform tesselation
    var pipelineTessellationStateCreateInfo = new VkPipelineTessellationStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_STATE_CREATE_INFO,
        PatchControlPoints = 1,
    };

    // we pass in defaulted arrays of size 1 for the viewports and scissors as we will set those dynamically
    var pipelineViewportStateCreateInfo = new VkPipelineViewportStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO,
        Viewports = [default],
        Scissors = [default],
    };

    // we want to rasterize filled polygons with the front face counter clockwise and cull the back face
    var pipelineRasterizationStateCreateInfo = new VkPipelineRasterizationStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_CREATE_INFO,
        PolygonMode = VkPolygonMode.VK_POLYGON_MODE_FILL,
        LineWidth = 1,
        CullMode = VkCullModeFlags.VK_CULL_MODE_BACK_BIT,
        FrontFace = VkFrontFace.VK_FRONT_FACE_COUNTER_CLOCKWISE,
    };

    // we dont use multisampling
    var pipelineMultisampleStateCreateInfo = new VkPipelineMultisampleStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO,
        RasterizationSamples = VkSampleCountFlags.VK_SAMPLE_COUNT_1_BIT,
    };

    // we dont use depth or stencil testing
    var pipelineDepthStencilStateCreateInfo = new VkPipelineDepthStencilStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_DEPTH_STENCIL_STATE_CREATE_INFO,
    };

    // we want to blend the source and destination colors using the alpha channel
    var pipelineColorBlendStateCreateInfo = new VkPipelineColorBlendStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO,
        Attachments =
        [
            new VkPipelineColorBlendAttachmentState
                {
                    ColorWriteMask = VkColorComponentFlags.VK_COLOR_COMPONENT_R_BIT | VkColorComponentFlags.VK_COLOR_COMPONENT_G_BIT | VkColorComponentFlags.VK_COLOR_COMPONENT_B_BIT | VkColorComponentFlags.VK_COLOR_COMPONENT_A_BIT,
                    BlendEnable = true,
                    SrcColorBlendFactor = VkBlendFactor.VK_BLEND_FACTOR_SRC_ALPHA,
                    DstColorBlendFactor = VkBlendFactor.VK_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
                    ColorBlendOp = VkBlendOp.VK_BLEND_OP_ADD,
                    SrcAlphaBlendFactor = VkBlendFactor.VK_BLEND_FACTOR_ONE,
                    DstAlphaBlendFactor = VkBlendFactor.VK_BLEND_FACTOR_ZERO,
                    AlphaBlendOp = VkBlendOp.VK_BLEND_OP_ADD,
                },
            ],
        BlendConstants = [0, 0, 0, 0],
    };

    // we only want to dynamically set the viewport and scissor
    var pipelineDynamicStateCreateInfo = new VkPipelineDynamicStateCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO,
        DynamicStates = [VkDynamicState.VK_DYNAMIC_STATE_VIEWPORT, VkDynamicState.VK_DYNAMIC_STATE_SCISSOR],
    };

    // build the graphics pipeline create info
    var graphicsPipelineCreateInfo = new VkGraphicsPipelineCreateInfoManaged
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO,
        Stages =
        [
            new VkPipelineShaderStageCreateInfoManaged
                {
                    Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO,
                    Stage = VkShaderStageFlags.VK_SHADER_STAGE_VERTEX_BIT,
                    Module = vertexShaderModule,
                    Name = "main",
                },
                new VkPipelineShaderStageCreateInfoManaged
                {
                    Type = VkStructureType.VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO,
                    Stage = VkShaderStageFlags.VK_SHADER_STAGE_FRAGMENT_BIT,
                    Module = fragmentShaderModule,
                    Name = "main",
                },
            ],
        VertexInputState = pipelineVertexInputStateCreateInfo,
        InputAssemblyState = pipelineInputAssemblyStateCreateInfo,
        TessellationState = pipelineTessellationStateCreateInfo,
        ViewportState = pipelineViewportStateCreateInfo,
        RasterizationState = pipelineRasterizationStateCreateInfo,
        MultisampleState = pipelineMultisampleStateCreateInfo,
        DepthStencilState = pipelineDepthStencilStateCreateInfo,
        ColorBlendState = pipelineColorBlendStateCreateInfo,
        DynamicState = pipelineDynamicStateCreateInfo,
        Layout = pipelineLayout,
        RenderPass = renderPass,
        Subpass = 0,
    };

    // create the graphics pipeline
    var graphicsPipelineCreateResult = graphicsBackend.Device.CreateGraphicsPipeline(default, graphicsPipelineCreateInfo, out var graphicsPipeline);
    if (graphicsPipelineCreateResult != VkResult.VK_SUCCESS)
    {
        Debug.WriteLine($"Failed to create vulkan presentable surface. Failed to create graphics pipeline: {graphicsPipelineCreateResult}", typeof(VulkanGraphicsPresentableSurface).FullName);
        presentableSurface = default;
        return false;
    }
    ds.Using(graphicsPipeline);

    // clean up the shader modules
    ds.Take(fragmentShaderModule).Dispose();
    ds.Take(vertexShaderModule).Dispose();

    // success
    presentableSurface = new(
        graphicsBackend,
        ds.Take(surface),
        surfaceFormat.Value,
        ds.Take(renderPass),
        ds.Take(pipelineLayout),
        ds.Take(graphicsPipeline));
    return true;
}

I also follow up with the extra verbose constructor for VulkanGraphicsPresentableSurface just to show the full pattern. Here we are constructing some things, quick and dirty, that we consider an exceptional case if they fail. We don't bother handling them explicitly, but also want to make sure we don't leak resources on the chance that something does go wrong, as that's a very bad thing to leave the API caller to deal with:

private VulkanGraphicsPresentableSurface(
     VulkanGraphicsBackend graphicsBackend,
     VkSurfaceKHR.Disposable surface,
     VkSurfaceFormatKHR surfaceFormat,
     VkRenderPass.Disposable renderPass,
     VkPipelineLayout.Disposable pipelineLayout,
     VkPipeline.Disposable graphicsPipeline)
{
    using var ds = new DisposableScope();
    ds.Using(surface);
    ds.Using(renderPass);
    ds.Using(pipelineLayout);
    ds.Using(graphicsPipeline);

    graphicsBackend.Device.CreateCommandPool(new()
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO,
        QueueFamilyIndex = (uint)graphicsBackend.QueueFamilyIndex,
    }, out _commandPool).ThrowIfNotSuccess();
    ds.Using(_commandPool);

    graphicsBackend.Device.AllocateCommandBuffer(
        _commandPool,
        VkCommandBufferLevel.VK_COMMAND_BUFFER_LEVEL_PRIMARY,
        out _commandBuffer).ThrowIfNotSuccess();
    ds.Using(_commandBuffer);

    // create our "is rendering complete" fence as initially signaled as we wait on it
    // to complete before starting our next frame
    graphicsBackend.Device.CreateFence(new()
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_FENCE_CREATE_INFO,
        Flags = VkFenceCreateFlags.VK_FENCE_CREATE_SIGNALED_BIT,
    }, out _isRenderingCompleteFence).ThrowIfNotSuccess();
    ds.Using(_isRenderingCompleteFence);

    graphicsBackend.Device.CreateSemaphore(new()
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO,
    }, out _isImageAcquiredSemaphore).ThrowIfNotSuccess();
    ds.Using(_isImageAcquiredSemaphore);

    graphicsBackend.Device.CreateSemaphore(new()
    {
        Type = VkStructureType.VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO,
    }, out _isRenderingCompleteSemaphore).ThrowIfNotSuccess();
    ds.Using(_isRenderingCompleteSemaphore);

    ds.Forget(_isRenderingCompleteSemaphore);
    ds.Forget(_isImageAcquiredSemaphore);
    ds.Forget(_isRenderingCompleteFence);
    ds.Forget(_commandBuffer);
    ds.Forget(_commandPool);
    _graphicsPipeline = ds.Take(graphicsPipeline);
    _pipelineLayout = ds.Take(pipelineLayout);
    _renderPass = ds.Take(renderPass);
    SurfaceFormat = surfaceFormat;
    Surface = ds.Take(surface);
    GraphicsBackend = graphicsBackend;
}

From these samples, what I have tried to do is recreate behaviour I would like from the language in the structure DisposableScope. Internally this keeps track of variables via the .Using method, and can either .Forget a variable (analogous to unusing) or .Take a variable (equivalent to .Forget then returning the value, and also what the elsewhere proposed move keyword might perform in this context). The key here is that this behaviour is possible to replicate in code using helper data structures, but doing so is not ideal as it requires keeping a dynamic list of boxed IDisposable instances in what would otherwise not need to perform heap allocations or list operations. I have shown in another post above how the codegen for this would be optimised if it were built into the language. For completion, here is the implementation of the DisposableScope struct (note the Debug.Assert in .Dispose that could be statically analyzed at the callsite instead of a runtime error in the case of first class support):

public readonly struct DisposableScope : IDisposable
{
    private readonly List<IDisposable> _disposables;

    public DisposableScope()
    {
        _disposables = [];
    }

    public readonly void Dispose()
    {
        // disposables should all be manually taken or forgotten before the scope is disposed. If they aren't it's assumed that we are unwinding
        // from an exception and we should dispose of them all. This is a check to make sure that we aren't disposing of them in a non-exception unwinding scenario.
        Debug.Assert(!(Marshal.GetExceptionPointers() == default && _disposables.Count != 0), "DisposableScope should only be disposing objects in the case of an exception");

        for (var i = _disposables.Count - 1; i >= 0; i--)
        {
            _disposables[i].Dispose();
        }
        _disposables.Clear();
    }

    public readonly void Using(IDisposable disposable)
    {
        _disposables.Add(disposable);
    }

    public readonly void Forget(IDisposable disposable)
    {
        if (!_disposables.Remove(disposable))
        {
            ThrowHelper.ThrowArgumentException(nameof(disposable), "Disposable not found in scope");
        }
    }

    public readonly T Take<T>(T disposable) where T : IDisposable
    {
        Forget(disposable);
        return disposable;
    }
}

I understand this is quite a specific scenario, and using a helper class like this isn't required where you instead check for all exceptions manually and ensure no code throws. This is the case for the _tryCreate as it was written first to manually handle exceptions. The VulkanGraphicsPresentableSurface constructor however was not, and the previous version before DisposableScope was not exception safe and would have leaked all the resources passed into it if something went wrong. Hopefully this can outline the kind of code I would like to be able to write easier without needing to resort to tools like this to properly ensure that my resources are all handled correctly. It can be done using a data structure like this, but all this does is empower the using statement in a way that I would rather have in the language itself for the multiple reasons listed before. There are many things here where I can write the wrong thing, and the resource tracking is not correct. When I take in the surface variable for example, I have no way outside of documentation to let the caller know that the resource is no longer its worry, that they are moving the resource into the functions care. If there was a way to dictate that as part of a greater "move semantics for IDisposable" design (possibly by allowing all declarations, function arguments included, to be using declarations) to the caller if the function "takes ownership" of an IDisposable, it would be possible to avoid mistakes with code like this.

I understand this has leaked a bit more into a general move semantics concept, but hopefully the experience I want can be better seen now, and it's also possible to see that doing it with data structures we can model in the language today is both verbose and error prone.

[iam3yal]

@Yen You can improve the implementation a bit, you can change DisposableScope to a readonly ref struct and because you know how many calls you make to Using you can use a fixed size array which is a lot cheaper as opposed to List<IDisposable> especially when you don't pass capacity so something like this:

public readonly ref struct DisposableScope
{
    private readonly IDisposable?[] _disposables;

    public DisposableScope()
        => throw new InvalidOperationException("Please provide a fixed length.");

    public DisposableScope(int length)
        => _disposables = new IDisposable[length];

    public void Dispose()
    {
        // disposables should all be manually taken or forgotten before the scope is disposed. If they aren't it's assumed that we are unwinding
        // from an exception and we should dispose of them all. This is a check to make sure that we aren't disposing of them in a non-exception unwinding scenario.
        Debug.Assert(!(Marshal.GetExceptionPointers() == default && _disposables.Any(d => d is not null)), "DisposableScope should only be disposing objects in the case of an exception");
        
        for (var i = _disposables.Length - 1; i >= 0; i--)
        {
            _disposables[i]?.Dispose();
            _disposables[i] = null;
        }
    }

    public void Using(IDisposable disposable)
    {
        for(var i = 0; i < _disposables.Length; i++)
        {
            if (_disposables[i] is null)
            {
                _disposables[i] = disposable;

                break;
            }
        }
    }

    public void Forget(IDisposable disposable)
    {
        for(var i = 0; i < _disposables.Length; i++)
        {
            if (ReferenceEquals(_disposables[i], disposable))
            {
                _disposables[i] = null;

                return;
            }
        }

        ThrowHelper.ThrowArgumentException(nameof(disposable), "Disposable not found in scope");
    }

    public T Take<T>(T disposable) 
        where T : class, IDisposable
    {
        Forget(disposable);
        return disposable;
    }
}

[Yen]

@iam3yal Yes thank you, there are optimisations to be made to this struct. If I wanted this as efficient as possible it would be a ref struct that takes in a stackalloc IDisposable span from the caller. This was made to be convenient in this case, but even avoiding dynamic association of the list completely, I still get every value type IDisposable I pass in boxed, and the allocation and virtual dispatch of that will likely cost more than a block of memory extra. This is only provided as an example of what language support could achieve, and the many ways it would do it better than what is practical if doing this by hand.

[Yen]

I am closing this as I have opened instead #7620 which I now think is a better solution to this problem. If I am supposed to wait for a team member to close this in my behalf, I can open it again. :)