Generate code to dispose of disposables inside of a collection type.

[AraHaan]

Issue Details

After looking at the code base currently, I noticed that this generator does not yet generate a foreach dispose loop for disposing of disposables that exist inside of a collection type. This must have been something I been overlooking as I rarely use collections to store disposables unless I am using Windows Forms and need to dispose of Windows Forms controls.

Is your feature request related to a problem? Please describe.
It's related to manual code can dispose of disposables using a loop that are disposed in a collection. All of the disposable work I feel should be source generated to ensure that everything is properly disposed of.

Describe the solution you'd like
For the source generator to properly generate the dispose loop for a collection that contains disposable objects. I am thinking an attribute for marking the collection would be sufficient as well.

Describe alternatives you've considered
Other than having the person tell the source generator to run their special function for disposing of items inside of said collection, I feel the best option would be to instead add direct support for it and then consider the future of having the special function attributes for running them on dispose.

Additional context
Implementing this would simplify C# code like this by generating it: dotnet/reproducible-builds#50

[Rekkonnect]

An interesting use case. Though I'm actually concerned about this being a potential feature bloat. In the linked PR, there exists a DisposableCollection type, which basically wraps a collection of IDisposable instances. This can be made generic, exposing the actual type that implements IDisposable and preserving the disposability logic. This will be automatically picked up by the generator as the field itself implements IDisposable, wrapping the internal logic.

Automatically disposing a collection is a dangerous path to follow, as the user could intend keeping the resources alive as they're wrapped inside a collection shared across multiple resources. The attribute approach sounds sane to me, and also avoids enforcing the user to use that custom DisposableCollection type.

Keep in mind that this will not be applicable to dictionaries. Should we also enable those and iterate the disposables via their Values property? Disposable dictionary keys are generally a bad practice to follow, so I doubt we must care about this.

Another thing to note here is that there is no way to extend the logic of the generated Dispose method. CommunityToolkit.Mvvm generates partial void methods that you can manually fill in with extra code, so this is a good pattern we could apply. For example,

// generated code:
public void Dispose(bool disposed)
{
    // dispose the fields
    DisposePartial(disposed);
}

partial void DisposePartial(bool disposed);

// user-implemented code:
partial void DisposePartial(bool disposed)
{
    // dispose our custom collection here.
}

Doing the partial disposability pattern sounds like a sane approach moving forward, which also avoids exposing user-consumable APIs like attributes. Disposing a collection of IDisposable is a greatly niche case that I could never imagine needing, so if a user needs it for whatever reason, they can manually type that into DisposePartial. For convenience, it would also be nice to have a DisposeCollection extension:

public static void DisposeCollection(this IEnumerable<IDisposable> disposables)
{
    foreach (var disposable in disposables)
    {
        disposable.Dispose();
    }
}

Overall I'm more a fan of the partial void method approach. We will also have to check whether this can be implemented in VB. If not, we can just offer it just for C#. VB users will be able to use the solution described above using the custom collection type wrapping the disposable instances.

[AraHaan]

I was thinking more or so collections that store disposables similar to the BCL's List<T> type.

But I agree, I guess using DisposePartial for user specified special dispose logic not covered with the existing attributes could work as well and would replace the need for [CallOnDispose]. Also I doubt that DisposePartial would need a param as it would only be called when bool disposing in the generated code turns out to be true to ensure that all callers would basically be only the generated dispose method. But just in case I think it should also generate docs for the stub in the generated code that it should only be called by the generated Disposal code.

[AraHaan]

Also, should the attributes be split into a separate package called IDisposableAnnotations or something like that as a Development Dependency and remove the need of having them in the Source Generator's resx file? Also then that assembly could be implemented in C# and usable in both C# and VB.

[Rekkonnect]

If we go down the partial method, I believe that the convenience would then be to have a DisposeRange extension, to quickly dispose an entire collection of disposables, as shown above. The CallOnDispose attribute would be an extra feature that basically offers a slightly simpler way to express a niche case. I wouldn't want to implement that one, but only the partial method and the extra package with the extension, or maybe even in the generated source itself.