Proposal: Destructible Types

stephentoub commented 9 years ago

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.

axel-habermaier commented 9 years ago

@casperOne: Interesting case. I would expect omod1 to be destructed when the assignment takes place, and omod2 being destructed when omod1 goes out of scope. In my opinion, that would match the original semantics of ref. Or am I missing something?

aelij commented 9 years ago

:+1: I love the idea of having RAII in C#.

Regarding delegates, I've often wondered why they were not value types to begin with. They're immutable, so copying them shouldn't matter. (I know a delegate can contain a list of delegates, but this is a less common use case, and I think it can be achieved by having a linked list of boxed delegates.)

So maybe as part of supporting "destructible delegate types", allow declaring any delegate type as a value type, which would avoid all those unnecessary allocations.

jaredpar commented 9 years ago

@aelij

The problem with maxing delegates value types is object tearing. At their core delegates are a tuple of object and method address and logically can be represented by the following:

struct Delegate 
{ 
  object _object;
  IntPtr _methodAddress;
}

The problem is that assignments between a struct of this nature are not guaranteed to be atomic. The CLR only guarantees atomic assignment for values that are one pointer in size (or less). This struct would be two pointers.

Having non-atomic assignments means that it is possible via assignment and multithreading to observe a Delegate value which has say _methodAddress from the location being assigned to and _object from the new value being assigned into it. Such a Delegate value has essentially violated type safety at that point because there is no guarantee the object and method address are a valid pair of values. Invoking it could succeed, cause the process to crash or worse fail but keep the process running.

This is one of the core reasons why delegates can't be value types, without other changes to the CLR these values are simply not fully type safe.

aelij commented 9 years ago

@jaredpar Thanks for the explanation! I wonder though if under some restrictions this might still be feasible (off the top of my head, only allow value type delegates on the stack and in read-only fields; this could cover many use cases -- such as LINQ.)

Sorry if I'm off on a tangent, this doesn't exactly pertain to this proposal.

jaredpar commented 9 years ago

@aelij unfortunately readonly fields aren't sufficient for the following reasons:

The CLR doesn't really enforce readonly. Sure it gives a verification error when it is violated but that's about it. Reflection, mishaving IL, etc ... can all assign after construction.
It is still possible to induce object tearing by without violating readonly inside a class. Have the constructor spawn off a thread which simply reads and invokes the delegate field. After spawning the thread the constructor just assigns the field different values inside of a loop. This is 100% legal and will produce torn objects.
A readonly field on a struct is even weaker than on a class. It is possible for the owner to effectively assign to fields by copying over the struct with a new value that differs in only the field that wants to be changed.

MgSam commented 9 years ago

...while I share many of your concerns about reducing the impact of the garbage collector I don't see how it's relevant to this issue.

@jaredpar Re-read the background section. The entire issue is framed as being necessary because of the non-determinism of the garbage collector. If you're going to solve a problem- solve the root cause, don't just add language bloat that dances around the issue.

I understand it's hard to get the CLR team onboard for huge, new major features. However, I think the scope of this problem more than justifies the two teams sitting down and doing that. When people compare .NET to other languages/runtimes, the garbage collector is the number 1 problem. It's time to find a solution that doesn't involve kludgy language-only half fixes. That's what the using statement was.

The CLR is not a black box- .NET development will be at a competitive disadvantage going into the future if the teams at MS keep treating it like one.

jaredpar commented 9 years ago

@MgSam

I'm well aware of the background section of this feature. I'm one of the designers of destructible types and I've previously implemented it in C#.

If you're going to solve a problem- solve the root cause, don't just add language bloat that dances around the issue.

I'm sorry but you're still trying to solve a different problem than destructible types. The goal of destructible types is to ensure a resource is freed at a very specific point in the program. This does not require making major changes to the GC. Why would we bloat the runtime for a simple language feature?

GitTorre commented 9 years ago

This is a great start! I vote Yay.

RobJellinghaus commented 9 years ago

Can you speak more to the interaction of references with destructible types in this proposal? Is it valid to take a ref to a destructible type? On its face it seems to me that it should be valid -- especially a readonly ref -- but I know from our previous experience that there can be issues here, to say the least. Some clarity on the interaction between ref and destructible would greatly help this proposal.

jaredpar commented 9 years ago

@RobJellinghaus

Yes taking a ref to a destructible would be legal. In this model the ref case actually represents the borrowed case.

paulomorgado commented 9 years ago

Even with @gafter's comment on dotnet/csharplang#6611, I can't help to feel that if you move the value out of a variable, that variable should be treated as not having a value, which is not the same as having the type's default value. The variable should be treated as not definitely assigned and, thus, not needing destruction.

As for fields, we can't get away with not being assigned.

jaredpar commented 9 years ago

@paulomorgado that is how we ended up defining it in our previous implementation. Essentially if we know the value definitely has no value via a move then we are free to treat it is unassigned.

There are some odd ball corner cases that you need to deal with but as a whole it works out.

danfma commented 9 years ago

Hey guys,

As a naive guy I could just say to put a delete keyword to forcely deallocate some object, executing the destructor. It's simple, effective but not safe at all.

But, in complement with that, we could grab the ideas from the rust language which defines borrowed pointers and that is only guaranted by the compiler (so no modifications at the runtime are needed). Most of what was discussed here are defined there.

Give a look at http://static.rust-lang.org/doc/0.6/tutorial-borrowed-ptr.html.

We need just some adaptations to make that more C#ish but I like some of that features. And believe me, when creating some games, or doing some other interoperability with existent libraries, deterministic finalization is a feature needed.

GitTorre commented 9 years ago

@danfma "As a naive guy I could just say to put a delete keyword to forcely deallocate some object, executing the destructor. It's simple, effective but not safe at all."

I don't think that's naïve at all (it's exactly what you need when memory needs to be freed exactly when you need it to be freed due to, say, memory pressure in the environment you have no control over...), but I agree it obviously breaks the memory safety guarantee of C# and .NET.

There are many scenarios where "escaping" GC in .NET is a reasonable (even critical) thing to do. This is an interesting idea, Dan. Of course, the problem is bigger than this particular feature (destructible types), but I do think "safedelete" is a reasonable (and obviously related) feature to consider. Borrowing from C++, D, Rust, these are all very reasonable things to do!

MgSam commented 9 years ago

A delete keyword is an obsolete solution before its even proposed- you used to have to do these kinds of things in Objective C before ARC came around. .NET should be looking at a more modern alternative for memory management that doesn't require all this explicit memory management that inevitably results in mistakes and thus bugs.

RobJellinghaus commented 9 years ago

A known valid pattern is to have a destructible local representing some resource, then pass it down to other objects and methods as a readonly ref. This ensures that those methods can rely on that reference not being deleted as long as they have access to it.

(It does require that the methods not capture the reference's value and expect it to remain valid, unless proper copy construction is provided.)

Code which follows this pattern can do a great deal to avoid any dynamic allocation at all. Generally speaking, in high-performance code, the less GC, the better. Rust gets this right. It may be too late for C# to ever support a GC-free model, but at least deterministic resource management features will enable the GC to be under far, far less pressure.

Adding a delete keyword is indeed a bad idea -- it precisely enables destruction of a value while references to the value still exist. Scoped destructible values, which become inaccessible at time of destruction, do not have the same issue.

paulomorgado commented 9 years ago

Just to be clear, @jaredpar, by definitely not assigned I mean all the rules for unassigned variables apply. It will be a compiler error, from then on, to read the variable without writing something to it first.

jaredpar commented 9 years ago

@paulomorgado yes, that is what I mean.

Grauenwolf commented 9 years ago

This whole thing is a really, really bad idea. By introducing the concept of a destructible type you have also introduced the question "Should my new type be disposable or destructible?".

That question is impossible to answer because you have no way of knowing how the consumer is going to use your type. And impossible design questions are pretty much a deal breaker for any new feature.

Furthermore, this is a lot of work to simply remove the need for a using statement. Semantically this is going to do exactly the same thing, it will just be less apparent when it will occur.

My third objection is that this will not play nicely with other languages. For this to work, the Common Language Specification will have to be updated to say that all compliant languages support the notion of destructible objects. This includes VB, F#, IronPython, IronRuby, and who knows how many other languages.

Finally, this is going to end up like checked exceptions. At some point we are going to get an escape valve of some sort that allows destructible objects to be wrapped in disposable objects. Once that happens, the meager guarantees this offers will evaporate.

drowa commented 9 years ago

I have some questions and points about this feature.

1) In case of destructible types, why do we need the move keyword if there is no other option? We could just assume the move semantics when necessary (i.e. in assignments, parameters and return statements).

Instead of writing...

var var2 = move var1;

We would write...

var var2 = var1; // `move` is implicit

2) Can a destructible type be a sub-type of a non-destructible type?

For example...

class A {}
destructible class B : A { } // is this valid?

Or...

destructible struct A { }
...
var var1 = new A();
object var2 = var1; // is this valid?

3) You can define the delete operator almost for free. This operator would be useful in long scopes and it would give more freedom to the programmer.

delete var1;

Would be translated to...

{var tmp$ = move var1;}

whoisj commented 9 years ago

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 commented 9 years ago

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

whoisj commented 9 years ago

@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. :smile:

govert commented 9 years ago

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:

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.)
Creating a [RequiresUsing] object outside a using block or some assignment to a field in a [RequiresUsing] type generates a compiler warning.
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).
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.
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 commented 9 years ago

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

govert commented 9 years ago

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.
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.
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 commented 9 years ago

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

govert commented 9 years ago

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 commented 9 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

alrz commented 8 years ago

It would be nice to merge this proposal with dotnet/csharplang#6611 and somehow dotnet/roslyn#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 dotnet/roslyn#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 commented 7 years ago

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 https://github.com/dotnet/roslyn/issues/18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I think https://github.com/dotnet/csharplang/issues/121 is the best place to continue this discussion.

dotnet / roslyn