Automatic Disposing

[TonyValenti]

Hi All,
I just finished reading the proposal for async streams and there were a few things that stood out to me:

1. It will take a lot more code to simply consume async streams.
2. There's a lot of using/disposable cases that I can imagine easily getting overlooked.

I wanted to give a suggestion as it relates to IDisposable.
Whenever an IDisposable is created, the compiler should track where it gets created and used and should automatically Dispose() of it if it can determine that it is no longer necessary.

For example:

//No automatic disposing happens here because ret "escapes":
private IDisposable CreateDisposable() {
  var ret = new DisposableObject();
  return ret;
}

private DisposableObject NotAutomatic;
private void Test(){
  CreateDisposable();
  //The compiler should automatically add a Dispose() to the result of the above
  //because its value is no longer used anywhere else.

  var Foo = CreateDisposable();
  Foo.Something();
  //Again, the compiler should add a Foo.Dispose() automatically.

  NotAutomatic = new CreateDisposable();
  //NotAutomatic will never be automatically disposed and a warning should be 
  //generated because it is never actually disposed from anywhere.
}

[yaakov-h]

As proposed, this is a breaking change and will almost certainly not be accepted.

#1703 proposes the inverse.

[YairHalberstadt]

If this were possible there would be no need for a Garbage Collector, and Rust would be a far simpler language.

Take a look at RAII in Rust for the complexities involved in statically working out when a resource is no longer in use.

In short this is impossible.

The idea of a using statement is that the programmer says "Trust me. I'm not going to use this any more, and if I do I'll get an exception".

For example:

\\Assembly 1
public object GetThing()
{
    //You have to look at the implementation of Return to know whether DisposableObject is returned by this method.
    return Return(new DisposableObject());
}

\\Assembly 2 - the compiler can't see whats happening inside this method. It can only see the public API
public object Return(object obj) => return obj;

[scalablecory]

I don't like this because it increases maintenance complexity for the developer. It means I need to read and understand an entire method, and understand which of my variables are IDisposable, and all the intricacies of how the compiler detects "usage", to understand what magic is applying to each variable when scope/method closes.

You may consider explicitness to be overly-verbose, but it makes things much more readable, and it's pretty rare to have a huge number of disposables in a single method so the cost isn't huge.

[theunrepentantgeek]

@TonyValenti The analysis required for proper escape analysis is complex, plus this would be a breaking change. Both of these mean that the chances of this happening are extremely low.

But, check out both #1398 (Champion "defer statement") and #1174 (Champion "Implicitly scoped using statement) for two suggestions that improve on the current using syntax.

[arekbal]

I think the feature/concept is very powerful, helpful and important. It's one of the biggest features that made C++ better than C. I also thought about it a lot...

And I greatly agree with others.

1. It would require new interface with special compiler support like IDroppable so to not break, currently allowed not-disposed IDisposables.
2. Even more, to make it efficient with value types it would require introduction of another non-unmanaged, non-class something because of how these 3 (class, struct, unmanaged) are behaving.
3. I don't like how you treat members. I would expect them to be dropped implicitly. Such IDroppable should do this implicitly and using IDroppable as member of class or struct should be disallowed (classes have finalizers, but they are less then ideal and relying on IDisposable is even worse).
4. List<T> and the family, on Remove would have to call destructor per element...
5. but what if they just borrow the item/wanna hold the references...

@YairHalberstadt kind of mentions, the ownership problem.

It is something, they had to fight with in C++ and got partially solved by moves.
So in C++ before... an assignment of vector<int> to a variable of same type, would involve calling copy constructor while in fact it would 'move' it. They, couple years ago introduced move constructor. But then, still today in C++ there is a problem of use after move... here in C# we could use after Dispose() and it seems to not be that severe. 🐰

So... such new non-unmanaged, non-class thing would have to deal with default assignment behavior of copying (for instance, by disallowing it), add some sort of move behavior or let types define their copy as move... and/or ask compiler to prevent use-after-move or use-after-copy(move).

All of these changes, together, are quite expensive.
In order to make it possible I would suggest starting with some of these smaller changes first, that could be used outside of that feature.
Just having that using improved is great.