using parameters

[Boomkop3]

Currently, when you pass a disposable object into a function there is no way to tell if it is disposed or not.

IDisposable thing = listener.MakeADisposable();
DoSomething(thing); // Is it disposed in here? Maybe, maybe not
thing.HelloThere(); // might throw ObjectDisposedException at runtime, might not

void DoSomething(IDisposable value) {
    // maybe this disposes value, maybe not
}

However, to know whether something is disposed after being passed into a method, you would need to recursively track the object after that method call boundary. Much like with nullable values. For nullable values, this issue was solved by adding an optional ? to the type. That way, you don't need to look further than the signature of the method being called.

For IDisposable objects there is no such solution currently. After it's passed into a method, the code analyzer would have to recursively check if the object is disposed or not. So instead, solutions like IDisposableAnalyzers just suggest you never dispose anything that you got from a parameter.

To provide a solution, I would like to propose:

IDisposable thing = new DisposableThing();
DoSomething(thing); // This method disposes thing
thing.HelloThere(); // warning: object might be disposed

// Makes some code simpler
void DoSomething(using IDisposable value) {
    // value will be disposed after reachting the end of this scope
}

// Reduces the chances of accidentally calling Dispose() repeatedly, by passing on responsibility
void DisposeObjectPlease(using IDisposable value) {
    // value will not be disposed after reachting the end of this scope
    DoSomething(value); // instead, it's disposed during this call
}

// Also allows you to make sure something is *not* disposed
void DoSomethingBad(IDisposable value) {
    using (value) {
        // compiler warning: injected value should not be disposed here
    }
    DisposeObjectPlease(value); // warning: injected value should not be disposed here
                                                  // warning: object might be disposed
}

// Does not break existing syntax
using (value) {
    DisposeObjectPlease(value); // will be disposed here instead
    DisposeObjectPlease(value); // warning: object might be disposed
}

[colejohnson66]

What's wrong with this?

public async void TalkTo(IDisposable client)
{
    using (client)
    {
        // Have an amazing conversation
    }
}

[franchyd]

Wouldn't be visible in ref assemblies. But that could then be solved with an attribute/analyzer.

[bbarry]

That method didn't create the client and doesn't fully control its lifetime. It shouldn't be disposing it.

[Boomkop3]

That method didn't create the client and doesn't fully control its lifetime. It shouldn't be disposing it.

Yep, just looking at the methhod signature there is not way to tell the ownership for that client is to that method. You'd want to be able to explicitly indicate that

[dlebansais]

Did you try IDisposableAnalyzers?

It might not be the answer for what you are trying to do, but it has helped me managing my disposable objects.

[Boomkop3]

I installed it into some of my existing projects, and it does not appear to fit my work. Thank you for the suggestion though!

[iam3yal]

@Boomkop3

AreYouStillThere(client); // might throw an ObjectDisposedException at runtime

In your example the above shouldn't throw ObjectDisposedException unless you cast IDisposable and use some members on client after it was disposed which they might throw but then if you really want to pass client around and worry about its state that might get disposed by some other method down the line then you should consider create a wrapper and handle that there the way it fits your needs.

[iam3yal]

@Boomkop3 It's not about whether it's my approach or someone else's... Based on your examples I genuinely think there's no problem here. It feels like your approach might be introducing complexity where none exists.

Similar to an explicit ? to indicate to method is responsible to ensure the input is not null rather than expecting it.

I might misunderstanding you but appending ? to the type of a parameter doesn't ensure the argument is not null... in nullable context it actually indicates that the parameter may accept null and the lack of it indicates it shouldn't accept null and yet is not enforced by default.

Now, annotating a method with using is not only verbose but misleading because the method wouldn't dispose the object automatically when it goes out of scope it' just an annotation to indicate it might be disposed before it goes out of scope but you do realize that this is a rare case that is not even remotely comparable to NRT? and there are straightforward solutions to your problem but then again if you still want to follow this path then creating an Analyzer is definitely an option.

Writing a wrapper around it just to indicate "this was disposed" is not making the problem simpler.

You're not writing a wrapper to indicate the object was disposed... you're writing a wrapper to prevent the disposal of the underlying object when it's passed around because only the caller should handle that.

Nor is locking any and all disposable instances into the scope they're created in. It can be

I'm not sure what do you mean by that.

but a bigger program would turn into one giant method. You're going to have to pass around these objects at some point.

Again, not sure what it means...

[iam3yal]

That's another approach with a wrapper, are you also going to wrap a string to ensure it's not assigned null?

Again, NRT and your proposal are not remotely comparable.

Creating wrappers to achieve null safety isn't the same as wrapping disposable objects to make them non-disposable for callees. The former would require a wrapper for every type, which is impractical, and even then, it wouldn't prevent null assignments, it would have to be checked at runtime and would throw unless paired with an Analyzer. The latter, by contrast, is less common but has a clear, straightforward solution that aligns with ISP (Interface Segregation Principle).

[iam3yal]

You don't need to create dedicated wrappers. In fact, have a google and find Nullable.

I might have explained it poorly but I'm aware about NRT and mentions it in my comment but my point was to emphasize the difference between a feature that is fairly common and do require a language intervention and another that imo doesn't.

Also NullableObject?.Someproperty?.SomeFunction() is checked at runtime, while parameters are not.

Something tells me you're mixing two independent features, the elvis operator ?. was introduced in C# 6.0 before NRT was introduced to the language which was introduced in C# 8.0.

It's just a check at compile time. But you seem to have a very different interpretation of what I am suggesting, what is your understanding?

Well, from the OP I understood you're asking for flow analysis for disposable objects but then on the comment you made above it seems like you overloaded the meaning to also dispose objects.

[iam3yal]

@Boomkop3 In C# the Elvis operator is considered to be ?. as opposed to the ternary conditional operator ?:.

[CyrusNajmabadi]

@Boomkop3 , @iam3yal is correct. We consider ?. to be the Elvis operator, not ?:.

[HaloFour]

This feels like a pretty backward use of IDisposable to me, I would never (or very rarely) expect the callee to be responsible for disposing of a resource which it did not create. That onus should be on the caller. I don't think the language should encourage this pattern. An analyzer could be written to do so based on an attribute applied to the parameter if you want to enforce this on your projects.

[HaloFour]

but right now there is no easy solution to this problem

An analyzer is definitely the easiest solution. Could probably be whipped up in a day or so and it would enforce lifetimes based on the rules that you deem appropriate.

[Boomkop3]

No it can't, unless you want to write an analyzer that recursively tracks trough every possible path a variable might possibly end up. But that would be slow, a lot of work, and would not be compatible with new C# features.

You could if, instead of a keyword you'd use a parameter attribute. No need to come up with lifetimes

[HaloFour]

No it can't, unless you want to write an analyzer that recursively tracks trough every possible path a variable might possibly end up.

Sure it could, the compiler exposes it's flow analysis capabilities to analyzers.

But that would be slow, a lot of work, and would not be compatible with new C# features.

It would be infinitely less work than changing the language. You could have this completed by the weekend. As a language feature, even assuming it got immediate support by the language design team, you're probably talking a minimum of two years before any feature could be shipped.

[Boomkop3]

You could have this completed by the weekend

I'd have to learn how to write analyzers first, perhaps over the weekend

[jnm2]

I think this concept makes sense as "ownership transfer."

[Boomkop3]

dotnet/roslyn-analyzers#1617