Proposal: Destructible Types

[stephentoub]

Background

C# is a managed language. One of the primary things that's “managed” is memory, a key resource that programs require. Programs are able to instantiate objects, requesting memory from the system, and at some point later when they're done with the memory, that memory can be reclaimed automatically by the system's garbage collector (GC). This reclaiming of memory happens non-deterministically, meaning that even though some memory is now unused and can be reclaimed, exactly when it will be is up to the system rather than being left to the programmer to determine.
Other languages, in particular those that don't use garbage collection, are more deterministic in when memory will be reclaimed. C++, for example, requires that developers explicitly free their memory; there is typically no GC to manage this for the developer, but that also means the developer gets complete control over when resources are reclaimed, as they're handling it themselves.

Memory is just one example of a resource. Another might be a handle to a file or to a network connection. As with any resource, a developer using C++ needs to be explicit about when such resources are freed; often this is done using a “smart pointer,” a type that looks like a pointer but that provides additional functionality on top of it, such as keeping track of any outstanding references to the pointer and freeing the underlying resource when the last reference is released.

C# provides multiple ways of working with such “unmanaged” resources, resources that, unlike memory, are not implicitly managed by the system. One way is by linking such a resource to a piece of memory; since the system does know how to track objects and to release the associated memory after that object is no longer being referenced, the system allows developers to piggyback on this and to associate an additional piece of logic that should be run when the object is collected. This logic, known as a “finalizer,” allows a developer to create an object that wraps an unmanaged resource, and then to release that resource when the associated object is collected. This can be a significant simplification from a usability perspective, as it allows the developer to treat any resource just as it does memory, allowing the system to automatically clean up after the developer.

However, there are multiple downsides to this approach, and some of the biggest reliability problems in production systems have resulted from an over-reliance on finalization. One issue is that the system is managing memory, not unmanaged resources. It has heuristics that help it to determine the appropriate time to clean up memory based on the system's understanding of the memory being used throughout the system, but such a view of memory doesn't provide an accurate picture about any pressures that might exist on the associated unmanaged resources. For example, if the developer has allocated but then stopped using a lot of file-related objects, unless the developer has allocated enough memory to trigger the garbage collector to run, the system will not know that it should run the garbage collector because it doesn't know how to monitor the “pressure” on the file system. Over the years, a variety of techniques have been developed to help the system with this, but none of them have addressed the problem completely. There is also a performance impact to abusing the GC in this manner, in that allocating lots of finalizable objects can add a significant amount of overhead to the system.

The biggest issue with relying on finalizers is the non-determinism that results. As mentioned, the developer doesn't have control over when exactly the resources will be reclaimed, and this can lead to a wide variety of problems. Consider an object that's used to represent a file: the object is created when the file is opened, and when the object is finalized, the file is closed. A developer opens the file, manipulates it, and then releases the object associated with it; at this point, the file is still open, and it won't be closed until some non-deterministic point in the future when the system decides to run the garbage collector and finalize any unreachable objects. In the meantime, other code in the system might try to access the file, and be denied, even though no one is actively still using it.

To address this, the .NET Framework has provided a means for doing more deterministic resource management: IDisposable. IDisposable is a deceptively simple interface that exposes a single Dispose method. This method is meant to be implemented by an object that wraps an unmanaged resource, either directly (a field of the object points to the resource) or indirectly (a field of the object points to another disposable object), which the Dispose method frees. C# then provides the 'using' construct to make it easier to create resources used for a particular scope and then freed at the end of that scope:

using (var writer = new StreamWriter("file.txt")) { // writer created
    writer.WriteLine("hello, file");
}                                                   // writer disposed

Problem

While helpful in doing more deterministic resource management, the IDisposable mechanism does suffer from problems. For one, there's no guarantee made that it will be used to deterministically free resources. You're able to, but not required to, use a 'using' to manage an IDisposable instance.

This is complicated further by cases where an IDisposable instance is embedded in another object. Over the years, FxCop rules have been developed to help developers track cases where an IDisposable goes undisposed, but the rules have often yielded non-trivial numbers of both false positives and false negatives, resulting in the rules often being disabled.

Additionally, the IDisposable pattern is notoriously difficult to implement correctly, compounded by the fact that because objects may not be deterministically disposed of via IDisposable, IDisposable objects also frequently implement finalizers, making the pattern that much more challenging to get right. Helper classes (like SafeHandle) have been introduced over the years to assist with this, but the problem still remains for a large number of developers.

Solution: Destructible Types

To address this, we could add the notion of "destructible types" to C#, which would enable the compiler to ensure that resources are deterministically freed. The syntax for creating a destructible type, which could be either a struct or a class, would be straightforward: annotate the type as 'destructible' and then use the '~' (the same character used to name finalizers) to name the destructor.

public destructible struct OutputMessageOnDestruction(string message)
{
    string m_message = message;

    ~OutputMessageOnDestruction() // destructor
    {
        if (message != null)
            Console.WriteLine(message);
    }
}

An instance of this type may then be constructed, and the compiler guarantees that the resource will be destructed when the instance goes out of scope:

public void Example()
{
    var omod = new OutputMessageOnDestruction("Destructed!");
    SomeMethod();
} // 'omod' destructed here

No matter what happens in SomeMethod, regardless of whether it returns successfully or throws an exception, the destructor of 'omod' will be invoked as soon as the 'omod' variable goes out of scope at the end of the method, guaranteeing that “Destructed!” will be written to the console.

Note that it's possible for a destructible value type to be initialized to a default value, and as such the destruction could be run when none of the fields have been initialized. Destructible value type destructors need to be coded to handle this, as was done in the 'OutputMessageOnDestruction' type previously by checking whether the message was non-null before attempting to output it.

public void Example()
{
    OutputMessageOnDestruction omod = default(OutputMessageOnDestruction);
    SomeMethod();
} // default 'omod' destructed here

Now, back to the original example, consider what would happen if 'omod' were stored into another variable. We'd then end up with two variables effectively wrapping the same resource, and if both variables were then destructed, our resource would effectively be destructed twice (in our example resulting in “Destructed!” being written twice), which is definitely not what we want. Fortunately, the compiler would ensure this can't happen. The following code would fail to compile:

OutputMessageOnDestruction omod1 = new OutputMessageOnDestruction("Destructed!");
OutputMessageOnDestruction omod2 = omod1; // Error: can't copy destructible type

The compiler would prevent such situations from occurring by guaranteeing that there will only ever be one variable that effectively owns the underlying resource. If you want to assign to another variable, you can do that, but you need to use the 'move' keyword (#160) to transfer the ownership from one to the other; this effectively performs the copy and then zeroes out the previous value so that it's no longer usable. In compiler speak, a destructible type would be a "linear type," guaranteeing that destructible values are never inappropriately “aliased”.

OutputMessageOnDestruction omod1 = new OutputMessageOnDestruction("Destructed!");
OutputMessageOnDestruction omod2 = move omod1; // Ok, 'omod1' now uninitialized; won't be destructed

This applies to passing destructible values into method calls as well. In order to pass a destructible value into a method, it must be 'move'd, and when the method's parameter goes out of scope when the method returns, the value will be destructed:

void SomeMethod(OutputMessageOnDestruction omod2)
{
    ...
} // 'omod2' destructed here
...
OutputMessageOnDestruction omod1 = new OutputMessageOnDestruction("Destructed!");
SomeMethod(move omod1); // Ok, 'omod1' now uninitializedl; won't be destructed

In this case, the value needs to be moved into SomeMethod so that SomeMethod can take ownership of the destruction. If you want to be able to write a helper method that works with a destructible value but that doesn't assume ownership for the destruction, the value can be passed by reference:

void SomeMethod(ref OutputMessageOnDestruction omod2)
{
   ...
} // 'omod2' not destructed here
…
OutputMessageOnDestruction omod1 = new OutputMessageOnDestruction("Destructed!");
SomeMethod(ref omod1); // Ok, 'omod1' still valid

In addition to being able to destructively read a destructible instance using 'move' and being able to pass a destructible instance by reference to a method, you can also access fields of or call instance methods on destructible instances. You can also store destructible instances in fields of other types, but those other types must also be destructible types, and the compiler guarantees that these fields will get destructed when the containing type is destructed.

destructible struct WrapperData(SensitiveData data)
{
    SensitiveData m_data = move data; // 'm_data' will be destructed when 'this' is destructed
    …
}
destructible struct SensitiveData { … }

There would be a well-defined order in which destruction happens when destructible types contain other destructible types. Destructible fields would be destructed in the reverse order from which the fields are declared on the containing type. The fields of a derived type are destructed before the fields of a base type. And user-defined code runs in a destructor before the type's fields are destructed.

Similarly, there'd be a well-defined order for how destruction happens with locals. Destructible locals are destructed at the end of the scope in which they are created, in reverse declaration order. Further, destructible temporaries (destructible values produced as the result of an expression and not immediately stored into a storage location) would behave exactly as a destructible locals declared at the same position, but the scope of a destructible temporary is the full expression in which it is created.

Destructible locals may also be captured into lambdas. Doing so results in the closure instance itself being destructible (since it contains destructible fields resulting from capturing destructible locals), which in turn means that the delegate to which the lambda is bound must also be destructible. Just capturing a local by reference into a closure would be problematic, as it would result in a destructible value being accessible both to the containing method and to the lambda. To deal with this, closures may capture destructible values, but only if an explicit capture list (#117) is used to 'move' the destructible value into the lambda (such support would also require destructible delegate types):

OutputMessageOnDestruction omod = new OutputMessageOnDestruction("Destructed!");
DestructibleAction action = [var localOmod = move omod]() => {
    Console.WriteLine("Action!");
}

The destructible types feature would enable a developer to express some intention around how something should behave, enabling the compiler to then do a lot of heavy lifting for the developer in making sure that the program is as correct-by-construction as possible. Developers familiar with C++ should feel right at home using destructible types, as it provides a solid Resource Acquisition Is Initialization (RAII) approach to ensuring that resources are properly destructed and that resource leaks are avoided.

[scalablecory]

I would prefer a way that allows me to apply this not just to new types but to existing code.

One issue I see is this essentially mimics std::unique_ptr, but without the ability to get() a reference that can easily exist in multiple places.

These two concerns are showstoppers for me and so I would not vote to include this in its current form.

Another issue as-is with this proposal is that when reading code, there's no obvious way to determine that a variable will have side effects when it goes out of scope. If there's not a move right next to it, there'd be no way to know.

I believe something closer to this would get about 90% of the way there and be a lot more usable: say a way to mark an IDisposable as unique, and keywords to move() and get() it:

var !con = new SqlConnection(...);
var !cmd = con.CreateCommand();
var !reader = cmd.ExecuteReader();

DbDataReader errorReader = reader; // error: did not move or get.
DbDataReader !movedReader = move reader; // nulls out reader
DbDataReader normalReader = get reader; // preserves movedReader

This would give scope-bound deterministic disposal, single ownership safety, obvious code readability, be immediately useful when using existing code, and I believe could be implemented without changing the VM similar to Nullable.

Additional safety regarding single ownership could be had by adding a weak reference designator that forces explicit ownership to exist elsewhere:

DbDataReader ^weakReader = reader; // implicit.

But, this may be of limited usefulness if "get reader" allows getting a raw instance. (Which, I think is very important to allow)

[ryancerium]

What if you used C++ stack allocation construction syntax to visually separate garbage collected objects from destructible objects? Would that allow any object to be destructible then? I think you'd need CLR support at that point though.

OutputMessageOnDestruction omod("Hello world!");

[RichiCoder1]

👍
@scalablecory Correct me if I'm wrong, but how much call is there for something equivalent to get()? What scenarios would it allow outside just ref passing into methods? Having it be very strict seems a plus in C# specifically.

[svick]

If you want to be able to write a helper method that works with a destructible value but that doesn't assume ownership for the destruction, the value can be passed by reference

Would this work together with readonly parameters (#115), so that I can create a method that works with the destructible value, but can't "steal" it, by making the parameter readonly ref?

You can also store destructible instances in fields of other types, but those other types must also be destructible types

Does that mean that array or List<T> of destructible type wouldn't be allowed? And that you would need something like DestructibleSinglyLinkedList<T> to have a collection of them?

[MrJul]

That's definitely something I want to see, and reminiscent of Rust with its compile-time checking. Generalized enough, one can imagine a core runtime that almost doesn't need the GC at all.

What about returning a destructible type? Would it need to be moved explicitly, clearly expressing giving the ownership to the caller:

destructible class Destructible { }

Destructible CreateDestructible()
{
    var value = new Destructible();
    return move value;
}

Or would it be implicit?

Destructible CreateDestructible() {
    var value = new Destructible();
    return value; // ownership automatically transferred to caller
}

If the caller doesn't use the returned value, is it destructed immediately, or only at the end of the current scope?

void SomeLongMethod() {
    CreateDestructible();
    // is the return value destructed already?
    Thread.Sleep(60000);
} // or is it only now, a minute later?

[scalablecory]

@RichiCoder1 from C++ experience, it is not uncommon to have one "owner" object and several other objects that still need to use the instance somehow. I can see the same need here.

Here's an exercise. Say FileStream was made destructible. I want to use it like such:

FileStream fs = new FileStream(...);

await WriteA(fs);
await WriteB(fs);

I still want to allow these other methods (and any objects they allocate in their use of it) to use it while maintaining strict lifetime control at a top level. A ref param won't work here if Write() is an async method that needs to put the FileStream into its state machine object.

[jaredpar]

@ryancerium

Would that allow any object to be destructible then?

No. One of the goals of this proposal is to have destruction be deterministic and getting that requires the implementation of the type obey certain restrictions. Hence it wouldn't be possible to make any type destructible simply by changing its construction syntax.

[Mr-Byte]

👍

This is one I've thought about several times, as having deterministic management of resources would be extremely useful in a lot of areas, such as scientific programming and game development.

Could this potentially be used to allow for deterministic management of heap allocated memory? Effectively implementing the C++ std::unique_ptr in C# for more deterministic memory management.

Can these types be stored in collections? I noticed the proposal requires that an object containing fields that are destructible must itself be destructible? How would that work with arrays and collections?

[ryancerium]

@jaredpar The new construction syntax idea was simply so that you could tell how objects are allocated at the point of allocation.

A a = new A(); // Destructible?
B b(); // Destructible!

C# has done a very good job of making things explicit at the call site and not just at the declaration site; ref and out parameters in particular come to mind. (That has long been a problem in C++ to the point that the recommendation is that out parameters be raw pointers and in parameters be references. Raw pointers! What is this, 1986?)

What are the other "certain restrictions"? Why couldn't the CLR initialize any given object type on stack memory instead of heap allocated memory and have the finalizer run when it goes out of scope if it hasn't been moved? There's lambda capture to worry about I suppose, and concurrent modification, neither of which is anything remotely resembling easy.

[jaredpar]

@ryancerium

I agree that being able to distinguish between the two types here is important. In the past we did consider taking a page out of the F# book here and doing the following:

use var A a = new A();  // destructible

The overall feeling when we did this was mixed. Sure it made the construction more obvious but there was also concern it was adding too much verbosity to the code. Eventually we ripped it out in favor of finding a better solution later on.

Why couldn't the CLR initialize any given object type on stack memory instead of heap allocated memory and have the finalizer run when it goes out of scope if it hasn't been moved?

It's not just moving that is a problem but even simple aliasing. If the implementation of a method should put this into the heap somewhere then it would be possible to have a destructed object floating around in what appeared to be a non-destructed state.

[ryancerium]

@jaredpar

it would be possible to have a destructed object floating around in what appeared to be a non-destructed state.

Good point, I take it for granted sometimes that C++ let's people do stupid things if they really feel like it. I assume you meant the implementation of a destructible object's method, so if you put this on the heap, wouldn't that invoke move semantics? @scalablecory has an excellent use case for using references to a destructible object, so it's going to be tricky not matter what.

I really like your sample syntax also, with a minor tweak. If that caused mixed feelings, I don't know what to tell you :-)

use a = new A(); // destructible shorthand, implicit var
use A a = new A(); // destructible longhand, explicit type

[RichiCoder1]

Maybe somehow allow destructible objects to be boxed and passed like normal somehow? Though that seems like it would have it's own flaws. And lists and arrays bring up their own problem. Especially if you wanted something like a destructible array.

[jaredpar]

@RichiCoder1

Boxing is definitely an option we explored and feel is necessary for completeness. We even called it simply Box<T>. The basic summary of it was:

• A box can be empty or have a value
• A box has a finalizer and it will destruct the contents of the box if it's not empty
• The contents of the box can be moved out of it

[RichiCoder1]

@jaredpar Sounds great an exactly what I was thinking about. I think a read a previous article about discussion around a destructible types internal. Maybe piggy back on other ideas in this thread and follow Nullable<T> and have OutputMessageOnDestruction! be shorthand for Box<T>. Something like.

File! file = File.GetFile("....."); // <--- Implicitly is boxed up.
files.Add(file);

Random thought; Possibly include generic constraint T : destructible so that you could do something like:

public destructible class DestructibleList<T> : IList<T> where T : destructible 
{
    // .. implementation
}

public void ProcesFiles(string folderName)
{
    DirectoryInfo di = new DirectoryInfo(folderName);
    use DestructibleList<File> files = di.GetFiles("*");
    foreach(File! file in files)
    {
         // ... do stuff
    }
    // ...files go away here.
}

Though that raises the next question is how would a list of destructible work with something like IEnumerable?

Addendum: How would destructible types play with async?

[tomasr]

Overall, I like the proposal, but a couple of things are not entirely clear to me.... would someone mind expanding on this:

• What would the code generated for a destructible type look like? Would such a type implement IDisposable implicitly, or something else? would it also generate a finalizer (it sounds like it wouldn't, but curious nonetheless)
• How would such types interact with other classes not part of the actual code?

[ufcpp]

A scope-based single-owned destruction is good idea in a certain situation, I like it, but there might be still many situations that the proposal can not solve.
I need the IDisposable for unsubscribing events more often than for managing sensitive resources. This kind of IDisposable could not be destructible, because typically it is nether in a method scope nor owned by a destructible object.

[sharwell]

I was originally concerned that destructable types could require VM changes which would have a negative impact on the performance of the garbage collector. I no longer believe that is the case. My current understanding of the proposal is the following (with the exception of lambda considerations):

• A destructable type is a struct which implicitly implements IDisposable. For the points that follow say this is struct D.
• An instance of D cannot be copied by value.
  • Assigning an instance of D to another location requires setting the original instance to default(D).
  • A method can have a parameter ref D obj or out D obj, which is used like any other ref or out parameter. However, if a method has a parameter D obj, it can only be used in conjuction with a transfer of ownership (e.g. by requiring the use of the move operator at the call site).
  • D cannot be used as a generic type argument (like a raw pointer in this respect).
  • D cannot be boxed (compiler enforced).
• default(D).Dispose() is a NOP.
• In D.Dispose(), fields in D which are destructable are disposed in the opposite order in which they are declared.
• Any declaration of a variable D which is not a field is implicitly wrapped in a using block which is closed at the end of the containing block.
• A field in type D2 may only have type D if D2 is also destructable.

The above rules could be expanded to support a destructable class:

• A destructable class is syntactic sugar for creating a destructable struct which wraps an instance of a reference type which implements IDisposable.
• Suppose you have destructable class T

  • The generated wrapper would look like:

      destructable struct TWrapper { public T _instance; }

  • The compiler treats a field or parameter of type T as though it were actually a field or parameter of type TWrapper.

  • If a class TDerived extends T, then TDerived must also be declared destructable.

  • A destructable class cannot have a user-defined finalizer, because a destructable class cannot be used in a context where the call to Dispose() is omitted.

The above is surely incomplete but may serve as a starting point for defining the semantics of destructable types.

[sharwell]

Regarding Box<T> - I could see a reference type Box<T> existing for the purpose of using a destructable type in a context where destructable types are generally not allowed, e.g. as a field in a non-destructable type.

destructable struct D { }

class T : IDisposable
{
  D _value1; // error
  Box<D> _value2; // allowed
  Box<T> _value3; // error - T is not destructable
}

When a destructable value is placed into a "box", ownership is assigned to that box. Box<T> implements IDisposable, but more importantly it has a user-defined finalizer. Use of Box<T> would be generally discouraged, but use of destructable types in general would be hindered if Box<T> was not provided, because all currently existing code uses non-destructable types and therefore could not hold instances of these new types.

[MrJul]

@sharwell I assumed by reading the proposal that a destructible type doesn't implement IDisposable. The nice thing about destructible types is that only the runtime can destruct an instance (when nothing is using it anymore), and it guaranties that it happens only once. IDisposable doesn't have those guarantees.

[svick]

@sharwell

A method can have a parameter ref D obj, but it cannot have D obj.

Why not? @stephentoub's proposal contains this:

var omod1 = new OutputMessageOnDestruction("Destructed!");
SomeMethod(move omod1); // Ok, 'omod1' now uninitializedl; won't be destructed

I think this is reasonable, i.e. if the parameter is not ref, it requires explicit transfer of ownership.

D cannot be used as a generic type argument (like a raw pointer in this respect).

So, collections of destructible types wouldn't be allowed (at least not without Box)? I think having those would be very useful.

[RichiCoder1]

@sharwell what @MrJul said. The implementation looks like something completely seperated from IDisposable. This would be more than than just syntactic sugar, but a completely new behavior.

I also agree with @svick in his assessment of your points.

[sharwell]

Use of destructable types in an array poses and interesting, but not insurmountable, challenge. Consider the following:

destructable struct D { }

...

D[] values = new D[10];

In this scenario, values is (semantically) treated as a destructable class (see previous post) containing 10 sequential instances of D. The implementation could actually emit this in metadata using the type D[], provided instances of this type are only used in contexts where destructable types are allowed. Perhaps a value type destructable struct DestructableArray<T> where T : destructable could exist in System.Runtime.CompilerServices to assist in the use of these types with the using construct. 💭

[sharwell]

@MrJul and @RichiCoder1: The implementation of IDisposable does not need to be exposed to the user. It is an implementation detail allowing destructable types in C# to be "lowered" to set of features provided by the underlying VM without requiring new runtime support. While IDisposable could be replaced by another equivalent type, simply using IDisposable allows the feature to be easily defined in terms of the existing using statement. Remember that if you can't box an instance of a destructable type, then you also cannot cast an instance of a destructable type to IDisposable.

[sharwell]

I think this is reasonable, i.e. if the parameter is not ref, it requires explicit transfer of ownership.

I agree, I updated my post above.

[sharwell]

So, collections of destructible types wouldn't be allowed (at least not without Box<T>)? I think having those would be very useful.

Right now I don't see a way to provide destructable guarantees for existing generic data types. Perhaps if we introduce a destructable generic type constraint, then a destructable type could be used for this parameter (or rather, must be used). Then you could require that use of the destructable type follows the semantic requirements for destructable types elsewhere.

[jaredpar]

@tomasr

The generated code for a destructible type would not have an IDisposable implementation or a Finalizer. These features exist to support non-deterministic destruction and add extra overhead to the runtime (in particular the finalizer). A destructible type would be deterministically destructed and hence these are not needed.

[whoisj]

Just a few points I'd like to have clarified in the proposal.

Given A a = new A(); destructible which of the following is the suggested usage (and by the way, I love the use A a = new A(); suggestion for callsite specification.

Taking a reference of a destructible reference is done via A b = a; or 'A b = ref a`? The later seeming significantly more expressive and deliberate.

Taking ownership of a destructible reference is done via A b = move a;, what will A b = a; result in? I'm very much hoping the later results in a compile time error -- or at least a warning.

Can ownership be taken from references? Is this allowed (I hope not)?
A a = new A();
A b = ref a;
A c = move b

Is it absolutely required that when move is used, the previous owner is left in an invalid state? Why not convert it into a reference state? Perhaps the syntax should be more like:

DT a = use DT(); // destructible, a owns it
DT b = own a; // b owns destructible, a is now a reference
DT c = ref b; // c is a reference
DT d = ref a; // d is a reference
DT e = own a; // exception, a is not current owners and cannot confer ownership

Regardless, I do think use of the special keywords for on assignment should be required for destructible. Without them, compile time checking is impossible / really difficult. Additionally, declaration time specification is ideal - class markup is also handy for requiring specific declaration mark up but I do not believe it should be the method of implementation.

Lastly, I didn't see this in the specification: what happens to all the references? Does the run-time set them all to null or is there some kind of destroyed operator being introduced? I very much hope that we're not expecting the developer to track the state of these things without support from the run-time.

@Grauenwolf I disagree completely. The disposable pattern has been a weakness of C# since its inception. The sooner we can be without it, the better. The fact that the Dispose method could be called by any interacting code has made the entire pattern fragile. For example: there are a number of Stream wrappers which dispose the underlying stream, expected or not. This is horrible because the owner of stream (the allocator) likely still needs the resource undisposed or they would have disposed it themselves.

[Grauenwolf]

Any proposal based on abandoning IDisposable is doomed from the outset due to backwards compatibility issues.

[whoisj]

@Grauenwolf I do not disagree. There is no possible way to abandon the disposable pattern for many years. However, given that the pattern is subject to misuse and can be an enforced cause of bugs it should be phased out over time.

To assume that because something is common that it must always be, is akin to assuming that because it is common for people to drive gasoline powered automobiles that electric powered automobiles should never be considered. I believe history will prove this assumption incorrect. 😄

[govert]

I would like to suggest a poor-man's version of this feature, where the existing IDisposable / using mechanism is extended by compiler help and syntactic sugar to assist with some of the specific problems in current use. This would be a bit like the FxCop rules, but built into the compiler, improving the use of the current feature but not providing hard guarantees. For example:

1. Add an attribute, say [RequiresUsing] to indicate that a class which implements IDisposable should only be constructed in a using block, or in an assignment to a field in another [RequiresUsing] type. (An alternative would be an interface that extends IDisposable.)
2. Creating a [RequiresUsing] object outside a using block or some assignment to a field in a [RequiresUsing] type generates a compiler warning.
3. In an IDisposable type, a field of a type that implements IDisposable can be marked as [Dispose]. The compiler will auto-generate a Dispose() (maybe with an existing Dispose() being called by the compiler-generated method).
4. Some syntax like use x = new A(); is just shorthand for using (x = new A()) {...} where the block extent is as small as possible in the method - until just after the last use of x. Feature like async / await and exception handling already works right with using.
5. Add any flow analysis that the compiler can easily do, to provide warnings for misuse, like cases where an object might be used after disposal - e.g. if it is passed to a method from inside a using block that stores the reference and would allow the reference to live beyond the call lifetime.

This does not address the move / ref ownership issues comprehensively, so provides no guarantee around deterministic disposal. But it has the great advantage of not adding a tricky new language concept, instead making the compiler more helpful in using the existing paradigm for deterministic disposal.

[paulomorgado]

1. So, instances of this cannot be created by factory methods.
2. So, instances of this cannot be created by factory methods. And no wrapper classes are allowed.
3. Can you elaborate on that?
4. Can you provide sample code?
5. How would you do that?

[govert]

1. Can the compiler check the call graph to ensure that the factory method is at some point made from a using callsite? Again, I see this at about the same level as a warning for a variable that is declared but never used, so use outside the expected scope is OK, but just generates a warning.
2. Wrapper classes should be OK. But the same story - the compiler does what it can, generated warning where there are potential problems and makes no new guarantees.
3. Might mean code like:

public class A : IDisposable
{
   [Dispose] B b;
}

would compile (checking the constraint B : IDisposable), and generate

public class A : IDisposable
{
   [Dispose] B b;
   public void IDisposable.Dispose()
   {
       b.Dispose();
       // maybe b=null;
       // maybe keep a flag isDisposed = true, throwing an exception if Dispose is called again.
   }
}

Point 4. Code like:

void DoStuff()
{
   use x = new A();
   x.DoStuff();
   DoOtherStuff();
}

is compiled as

void DoStuff()
{
   using (var x = new A())
   {
       x.DoStuff();
   }
   DoOtherStuff();
}

Point 5. The compiler can detect cases like:

[RequiresUsing]
public class X : IDisposable { ... }

void DoStuff()
{
   using (var x = new X())
   {
       DoSomethingWithX(X)
   }
   UseXLater();
}

X _myX;
void DoSomethingWithX(X x)
{
    _myX = x; // Compiler should generate a Warning here: Assignment of `[RequiresUsing]` type to non-local variable.
}

void UseXLater()
{
  _myX.DoStuff(); // Dangerous - _myX might have been disposed already
} 

[paulomorgado]

1. What if the factory method is in a library for third party use (like a class in the .NET framework)?
2. What if the wrapper class is in a library for third party use (like a class in the .NET framework)?
3. What if there are more than one disposable and order of disposal is important?
4. What if the disposable is something like TransactionScope that is not really used inside the using statement?
5. How is x being used later if it's out of scope?

[govert]

For your 1. and 2. I understand your concern is some method like:

[RequiresUsing] public class A : IDisposable {...}

public A CreateA()
{
    var a = new A();
    a.PrepareFurther();
    return a;
}

This code should not raise a warning, since it returns the IDisposable. The warning is raised where an IDisposable is assigned to a local variable or non-special field, not returned from the function and not under a using.

For 3. The order of disposal is in the declaration order. For another order, implement Dispose() explicitly.

For 4. Then the use .... shortcut syntax is not appropriate - using is quite nice in that case, because it introduces the explicit syntactic block scope.

For 5. That's an example where the compiler might raise warning (the IDisposable escapes the scope of the using) but also shows where it becomes difficult to detect potential problems.

Anyway, I'm just trying to suggest exploring a lightweight approach to the problems addressed by this topic, but which is complementary to the existing IDisposable / using mechanism and without the severe complications added by the 'destructible' proposal offered before. I'm not sure this thread is the place, or that I could, work towards a comprehensive counter-proposal. Is there any merit in considering an attributes-and-compiler-warnings approach to the problem?

[bbarry]

@govert I think that code should raise a warning. The IDisposable semantics are not being recognized in that method somehow. You should do something explicit to not get it:

Given:

[RequiresUsing] public class A : IDisposable {...}

This should give a warning to the effect of IDisposable instance marked with RequiresUsingAttribute not disposed

public A CreateA()
{
    var a = new A();
    a.PrepareFurther();
    return a;
}

In this case an analyzer could offer the fix (because A is the return type) of putting the attribute on the method:

[RequiresUsing] public A CreateA()
{
    var a = new A();
    a.PrepareFurther();
    return a;
}

You could also detect class level usages:

public class B {
    //warning: should implement IDisposable to use IDisposable field of type A
    //warning: should call _a.Dispose() in Dispose method
    //warning: should be marked with RequiresUsingAttribute
    private readonly A _a;
    public B() { _a = ...; }
}

//OK 
[RequiresUsing] public class B : IDisposable {
    private readonly A _a;
    private bool _disposed = false;
    public B() { _a = ...; }
    public void Dispose() { Dispose(true); }
    public virtual void Dispose(bool disposing) {
        if(!_disposed) { _a.Dispose(); } 
        _disposed = true;
    }
}

I think there is merit to such an approach and it could be done entirely with attributes and analyzers without changes to the compiler.

[drauch]

@bbarry: although the feature is already on the "probably never" list, I want to point out that you cannot easily workaround such using-enforcements, e.g., what to do in NUnit tests where you have a SetUp and a TearDown method? How to tell the system that the Dispose() method is called by reflection?

[bbarry]

@drauch [SuppressMessage("Acme.RequiresUsing", "AR....", Justification = "Disposed via reflection.")]

[alrz]

It would be nice to merge this proposal with dotnet/csharplang#6611 and somehow #181, so

// instead of
var foo = new Destructible();
var bar = move foo; // mandatory move

// we could just
let foo = new Whatever(); // owned by scope
{
  let bar = foo; // implicitly (temporarily, in this case) move 
  foo.Bar(); // ERROR: use of moved value
}
foo.Bar(); // OK

This would cause a compiler error when accessing the collection in foreach block, which is not possible with neither dotnet/csharplang#6611 nor #161, e.g.

let list = new List<T> { ... };
foreach(var item in list)  // list is borrowed
{
  WriteLine(item);
  list.Add( ... ); // ERROR: use of moved value
}
list.Add( ... ); // OK

Probably another keyword instead of let (perhaps, using?) but basically what Rust features. Note that if the type is IDisposable it'll be disposed when it gets out of scope, just like Rust's Drop — so you'll never forget to dispose IDisposable objects with let or whatever.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I think dotnet/csharplang#121 is the best place to continue this discussion.