Proposal: Provide an 'IDestroyable' contract for cleaning up object instances.

[maelgrove]

A lot of types within the .NET framework, other Microsoft platforms and frameworks (ASP.NET., ASP.NET Core, EF..) as well as 3rd party libraries and tools currently use the IDisposable contract to indicate types (mostly infrastructure-related services) which can be cleaned up after use, mostly for stylistic purposes thanks to the using statement in C#. However, the MSDN documentation clearly states that...

Provides a mechanism for releasing unmanaged resources.

The idea: Provide an IDestroyable contract which can be used together with using (or a new statement block such as use or scope which indicates that a type will be destroyed using a custom routine when it leaves a certain scope, irregardless of having managed/unmanaged resources.

public interface IDestroyable {
    void Destroy();
}

Usage:

using(var timeService = new TimeService()) //implements IDestroyable
{

} // calls .Destroy()

Additionally, a UnmanagedResourcesAttribute could be introduced that could be used to decorate types implementing IDisposable which actually contain unmanaged resources. When using a type with IDisposable which isn't annotated with UnmanagedResourceAttribute, the compiler could produce a warning indicating that IDisposable might have been misused. When a developer allocates a type that implements IDisposable and has a UnmanagedResourcesAttribute, but doesn't dispose it anywhere in code, a warning could be produced that unmanaged resource aren't released during the lifetime of a type (though this could be harder to track).

This ultimately would allow continue using the using statement for style preferences, but would do away with the confusion whether a type now contains unmanaged resources or not.

---

Edit: I just saw this might be overlapping with #121 and dotnet/roslyn#161, but proposes a slightly different approach by explicit contract implementation.

[ig-sinicyn]

However, the MSDN documentation clearly states that...

Wouldn't be fixing the docs much simpler thing? ;)

[maelgrove]

@ig-sinicyn I have a feeling this might actually lead to much greater confusion since the IDisposable contract derives it's name from the dispose pattern whose purpose is clearly resource management, especially in managed programming languages (though I don't know how other languages like Java and the like implement it). If the documentation would be fixed (would you also suggest fixing the definition of a hammer if everyone would start using it as a screwdriver?), we'd end up with a contract that conveys a different purpose through its name AND would be something different to many programmers who read the docs prior to the change.

[svick]

@maelgrove I think that in this case, changing what "dispose" means is better than introducing a completely new concept, interface and possibly syntax. (Just like for example SslStream by default does not actually support SSL anymore, AFAIK, but was not renamed to TlsStream.)

Additionaly, I don't see how "destroy" is any better than "dispose".

[jnm2]

Yes, the MSDN docs are out of date.
Previous conversation on this topic: #93 (comment)

[ufcpp]

So far, IDisposable cannot force its usage: releasing unmanaged resources. Many people use this interface as just scoping purpose, e.g. Rx.
If I add a new interface, I prefer the following with Default Methods instead of IDestroyable.

public interface ICriticalDisposable : IDisposable
{
    void Dipose(bool isDisposing);

    override void Dispose()
    {
         Dispose(true);
        GC.SuppressFinalize(this);
    }

    // allow finalizer, disallow implementation by structs
    ~ICriticalDisposable() => Dispose(false);
}

[jnm2]

That's kinda what's out of date. You shouldn't be doing any of this for unmanaged resources anymore:

    void Dispose(bool isDisposing);

    override void Dispose()
    {
         Dispose(true);
        GC.SuppressFinalize(this);
    }

    // allow finalizer, disallow implementation by structs
    ~ICriticalDisposable() => Dispose(false);

Instead, wrap it in a SafeHandle (which implements CriticalFinalizerObject) and do this:

class ClassWithUnmanagedThings : IDisposable
{
    public void Dispose()
    {
        handleOfUnmanagedThing.Dispose();
    }
}

[sharwell]

This ultimately would allow continue using the using statement for style preferences, but would do away with the confusion whether a type now contains unmanaged resources or not.

In almost every project I've been involved in¹, I've been highly successful in eliminating the confusion surrounding IDisposable by following one simple, sustainable rule:

If the type is defined in the code of the project, then one of the following holds:

1. The type does not own unmanaged resources
2. The type extends SafeHandle or CriticalHandle, and owns exactly one instance of exactly one unmanaged resource

Under these rules, IDisposable is never (and shall not be) used to indicate a type has unmanaged resources, making the proposal for IDestroyable obsolete in practice.

¹ The Roslyn project breaks this in a number of places, but I'm pushing hard to eliminate them over time in practice and then in policy.

[jnm2]

Yes, thank you! Well put. I'm going to link people to this because this is exactly what I have been doing in practice.

[HaloFour]

@sharwell

Under these rules, IDisposable is never (and shall not be) used to indicate a type has unmanaged resources ...

It's so interesting to hear that when other members of the team argue against the use of IDisposable/using to indicate unit-of-work operations that don't involve unmanaged resources.

[jnm2]

@HaloFour I've heard a few community members argue that but so far no team members.

http://joeduffyblog.com/2005/12/27/never-write-a-finalizer-again-well-almost-never/

And an article by @stephentoub so old that you need https://web.archive.org/web/20080704160625/https://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/ (or download the now-archived MSDN mag as .chm)

[kevingosse]

I've heard a few community members argue that but so far no team members.

Eric Lippert has always defended on StackOverflow a strong stance against usage of using for scoping purpose. There are bits here and there but here is a complete answer that summarizes his position: https://stackoverflow.com/a/2103158/869621

I'm personally all-in to allow using outside of the unmanaged resources use-case, but it's really interesting to see the point of view of somebody who has worked in the compiler team and spent years writing about the design choices behind C#.

[Joe4evr]

Amusingly, another answer on that very same SO question mentions another dev from the Language Design Team answering a question about using:

When we decided[sic] the using statement, we decided to name it “using” rather than something more specific to disposing objects so that it could be used for exactly this scenario.

So yeah, the views seem to be fragmented even among the people who make the language.