[Proposal]: Introduce a disposable Keyword in C#

[Tommigun1980]

Proposal: Introduce a disposable Keyword in C#

Summary

This proposal introduces a disposable keyword in C# to explicitly mark objects that implement IDisposable at the point of declaration. The goal is to enhance code clarity and prevent unnoticed misuse of disposable objects.

Motivation

In the current state of C#, any object can implement IDisposable, but this is not apparent to developers unless they inspect the source code or documentation. This ambiguity leads to several issues:

1. Hidden Responsibility: Developers may unknowingly use a disposable object without proper cleanup, leading to resource leaks.
2. Tooling Limitations: The compiler and static analysis tools cannot enforce proper disposal unless explicitly wrapped in a using statement or manually disposed.
3. Cognitive Overhead: Developers must check each object's source or documentation to determine if it is disposable, slowing down development and increasing the risk of errors.

This proposal aims to address these issues by requiring developers to explicitly acknowledge disposability at the point of declaration using a disposable keyword. This is similar in philosophy to ref and out at call site, which enforce clarity and intent.

---

Design Proposal

1. disposable Keyword for Local Variables

The disposable keyword is used when declaring local variables that implement IDisposable. This ensures developers are immediately aware that the object requires cleanup.

Example:

disposable var connection = new SqlConnection(connectionString);

• Compiler Enforcement: If a disposable object is declared without the disposable keyword, the compiler raises an error.
• Tooling Benefits: Tools like analyzers can enforce cleanup paths (using, explicit Dispose, etc.).

2. disposable for Fields and Properties

Fields and properties holding disposable objects must also use the disposable keyword. This explicitly indicates that the object implements IDisposable and highlights the need for proper resource management, making its lifecycle requirements clear.

Example:

class DatabaseManager
{
    disposable SqlConnection _connection;

    public void OpenConnection(string connectionString)
    {
        _connection = new SqlConnection(connectionString);
        _connection.Open();
    }

    ~DatabaseManager()
    {
        _connection?.Dispose();
    }
}

• Class-Level Benefits: Clearly communicates that _connection is a disposable object and that developers must take responsibility for ensuring it is properly disposed of during the object's lifecycle.

3. Integration with using

The using keyword already implies disposable management. No changes are required for using declarations or blocks, as using already enforces disposal.

Example:

using var connection = new SqlConnection(connectionString);

---

Key Benefits

1. Prevents Hidden Disposability: By requiring explicit acknowledgment, developers are no longer surprised by objects that implement IDisposable.
2. Improved Developer Experience: No need to inspect source code to determine if an object is disposable.
3. Compiler and Tooling Support: Enables more robust static analysis and guarantees proper disposal paths.
4. Consistency Across Scopes: Works uniformly for local variables, fields, and properties, ensuring clarity throughout the codebase.

---

Opt-In or Automatic

The disposable keyword could be:

1. Opt-In (like nullable reference types): Allow projects to enable this feature with a compiler flag, such as <EnableDisposableEnforcement>true</EnableDisposableEnforcement>.
2. Default for New Versions: Enable by default in future C# versions, ensuring consistent adoption while minimizing disruption to legacy code.

---

Comparison to Current State

Aspect	Current	Proposed
Discoverability	Requires checking docs/source	Clear at declaration (disposable)
Compiler Enforcement	None	Compiler enforces usage and cleanup
Developer Awareness	Relies on knowledge or tooling	Explicitly visible in code
Risk of Resource Leaks	High	Significantly reduced

---

Conclusion

A disposable keyword provides an elegant solution to a longstanding issue with IDisposable handling in C#. By making disposability explicit and enforceable, it improves code safety, clarity, and developer productivity. This proposal aligns with C#'s focus on modern, safe, and clear language design and deserves serious consideration.

[HaloFour]

Sounds like a good use case for a custom attribute and an analyzer.

[Tommigun1980]

Sounds like a good use case for a custom attribute and an analyzer.

Hi @HaloFour. It is not the same thing. C# already enforces certain keywords, such as out and ref, to ensure proper usage independently of in-house tooling or custom analyzers. These keywords exist to make code safer, reduce ambiguity, and provide immediate feedback through the compiler.

Relying on custom attributes and analyzers introduces issues:

1. Non-Standardization: Attributes and analyzers depend on external tooling that may not be universally adopted or consistently implemented across teams or projects.
2. Compiler Integration: A keyword integrated into the language allows the compiler to enforce rules immediately and universally, whereas attributes and analyzers only work after specific tooling is configured.
3. Discoverability: Keywords like ref and out make behavior clear at the point of use, while attributes require additional knowledge or inspection of external rules.

The disposable keyword ensures consistent, built-in handling of disposable objects without relying on optional, team-specific tooling. This elevates it to a universally understood and enforced standard, benefiting the entire ecosystem.

[theunrepentantgeek]

Suggestion: try writing a custom analyzer. They're a good way to expand on understanding and consequences of the proposal. A good custom analyzer that shows significant value would be a strong argument towards language standardization. On the other hand, if (as I suspect) you find that there are a whole bunch of negative side-effects, you get to explore those relatively cheaply.

[CyrusNajmabadi]

Non-Standardization: Attributes and analyzers depend on external tooling that may not be universally adopted or consistently implemented across teams or projects.

This also applies to any new feature of the language. You will still have teams using older compilers taht do not understand that feature.

[Tommigun1980]

Suggestion: try writing a custom analyzer. They're a good way to expand on understanding and consequences of the proposal. A good custom analyzer that shows significant value would be a strong argument towards language standardization. On the other hand, if (as I suspect) you find that there are a whole bunch of negative side-effects, you get to explore those relatively cheaply.

Thanks for the suggestion regarding custom analyzers. However, code is primarily for people to read and only occasionally compiled. Custom analyzers only help with the latter but don’t make disposability visible in the code itself. The disposable keyword directly addresses this, improving clarity and discoverability where it matters most—while reading the code.

Similar to how ref and out make call-site intent explicit, the disposable keyword ensures that disposability is immediately apparent at the point of declaration.

[theunrepentantgeek]

A custom analyzer could easily require a specific attribute [Disposable] or comment // disposable to be present, as appropriate for the context, achieving your requirement for visibility.

I repeat my earlier point - with an analyzer you can prove the utility (or not) of the idea yourself.

[theunrepentantgeek]

Compiler Enforcement: If a disposable object is declared without the disposable keyword, the compiler raises an error.

This is making the assumption that any disposable object that's stored in a local variable must be disposed by the method making that declaration.

This is obviously false.

It's extremely common to pass around disposable objects like connections, caches, and similar, for consumption by other code that has no part to play in the lifetime of the object.

You're also talking about making a breaking change that would impact literally billions of lines of existing code.

[Tommigun1980]

Hi @theunrepentantgeek. This is a misunderstanding of the proposal. The disposable keyword does not enforce a scope-based disposal or mandate that every disposable object declared locally must be disposed by the declaring method. Instead, it ensures that developers explicitly acknowledge that an object is disposable when it is instantiated.

Reasoning is as thus:

• Avoids Hidden Disposables: Currently, it is possible to instantiate a disposable object without realizing it implements IDisposable, unless you read the documentation or source code. This proposal addresses that by requiring a disposable keyword at declaration—similar to how ref and out enforce clarity for method arguments. It simply gives a compiler error if a disposable object is instantiated without acknowledgment.

• Not a Lifetime Enforcer: The proposal does not impose or assume any specific lifetime management rules for the object. Developers are still responsible for deciding when and how to dispose of the resource. For example:

  disposable var connection = new SqlConnection(...);
  UseConnection(connection); // The lifecycle can be managed elsewhere

• Enhances Clarity, Not Behavior: This is not about changing runtime behavior or enforcing disposal in a specific scope. It’s purely about ensuring that developers are aware they are working with a disposable object. The responsibility for disposal remains unchanged.

As for breaking changes: this proposal is explicitly opt-in (like nullable reference types), meaning existing billions of lines of code remain unaffected unless the feature is enabled. Teams adopting it benefit from additional clarity and error prevention moving forward without disruption to legacy code.

This proposal ultimately improves safety and discoverability without altering how IDisposable itself works or how developers manage resource lifetimes. It’s about making disposable objects unmissable at the point of instantiation—a pain point that the current language design fails to address effectively.

[CyrusNajmabadi]

similar to how ref and out enforce clarity for method arguments

These actually change the semantics. For example, by actually passing a variable by-ref, instead of by-value.

[HaloFour]

As for breaking changes: this proposal is explicitly opt-in (like nullable reference types), meaning existing billions of lines of code remain unaffected unless the feature is enabled.

The team was only willing to give NRTs this treatment because null reference exceptions are widely considered to be a "billion dollar mistake".

[Tommigun1980]

similar to how ref and out enforce clarity for method arguments

These actually change the semantics. For example, by actually passing a variable by-ref, instead of by-value.

The comparison to ref and out is about syntactic clarity when calling methods, not about implementation semantics. At the call site, ref and out are purely syntactic sugar to make it explicit that a parameter is passed by reference. Their runtime effect only matters during method implementation.

Similarly, the disposable keyword ensures that disposability is visible at the point of declaration. It doesn't change runtime behavior but provides the same level of clarity as ref and out do for method calls, ensuring that disposability is not hidden or overlooked.

I very much enjoy this syntactic sugar in C# as opposed to say how method argument references are transparent in C++, as it makes it evident when reading code that the in arguments can/will be modified, and the compiler gives an error if the user failed to acknowledge this. I'd enjoy the same level of clarity for disposable objects, which imo. is a mistake in C#. This would alleviate the biggest issues with it.

[CyrusNajmabadi]

The comparison to ref and out is about syntactic clarity when calling methods, not about implementation semantics. At the call site, ref and out are purely syntactic sugar to make it explicit that a parameter is passed by reference.

This is not hte case. Consider something like:

Foo(v);

void Foo(V v) { }
void Foo(ref V v) { }

It's not syntactic clarity. It is necessary for ensuring the callsite calls the desired method.

[CyrusNajmabadi]

If this is simply about a particular API/pattern wanting additional diagnostics, then teh team position is that this is exactly the space for custom analyzers.

[Tommigun1980]

Hi @CyrusNajmabadi. This proposal isn't about diagnostics or analyzers; it's about improving code clarity and language consistency. Like ref and out (at call site), the disposable keyword makes intent explicit and ensures developers know when an object is disposable.

Unlike custom analyzers, this approach works universally without requiring external tools and highlights disposability directly in the code, improving readability and reducing the need to check documentation.

It addresses a systemic issue by embedding disposable awareness into the language without adding complexity. Thanks for considering.

[CyrusNajmabadi]

it's about improving code clarity and language consistency

Right. You want to require something at creation to indicate that the user knows this is disposable. And you want the compiler to error if the user doesn't provide that. An analyzer/fixer can do this.

[ufcpp]

#1451

[En3Tho]

Seems like this proposal is a limited version of general ownership model. I dont think doing aomething like this is feasible before doing a genral ownership feature exploration.

Simply labeling field as disposable doesn't save you in a case of multithreaded ownership and and potential problems that go with it.

I don't see any mention of use after free (dispose) analysis and how this feature interacts with it.

I dont not see any mention of async disposal too.

Even assuming this feature is about forcing disposal in a very small context It is not clear how compiler should be able to enforce that if face of exceptions.

This rather feels like a hint that "hey, please dispose this after youre done" which is in fact a case for an analyzer.

I don't see how this limited feature can really help especially when we might have roles/shapes/extensions (whatever they are called now) like Disposable<T> which can act as opaque wrspper giving the same sort of hint as proposed keyword