Memory management of Swift projections in .NET

[kotlarmilos]

Description

Currently, Swift types are typically projected as C# classes that implement IDisposable.

public class SwiftType: IDisposable
{
    private IntPtr handle;
    public void Dispose() { }
}

Ideally, users should not need to be concerned with memory management in C#; it should be handled by the projection tooling. However, by projecting Swift types as IDisposable, there is a set of challenges that users need to address in order to release memory properly, which goes against the typical .NET approach.

This has been handled differently depending on the runtime. Mono accomplishes this by exposing runtime APIs, while CoreCLR relies on C# exposed APIs. Additionally, there is a question of how COM interop handles this challenge.

Let's brainstorm ideas and update the design document based on feedback.

[AaronRobinsonMSFT]

Swift types are typically projected as C# classes that implement IDisposable.

Is this meant to mean managed instances of a Swift type or projection of the concept, akin to instances of System.Type?

[jkotas]

However, by projecting Swift types as IDisposable, there is a set of challenges that users need to address in order to release memory properly, which goes against the typical .NET approach.

IDisposable pattern (often combined with finalizer as a back-stop) is the typical .NET approach for dealing with unmanaged resources.

What are these challenges? Is the problem that IDispose on every type leads to too verbose code that the users have to write?

[jkoritzinsky]

Do we have the same object-identity problems with Swift that we have with COM/WinRT/Objective-C? Generally, the object identity problem + unmanaged ref counting has been the driving force for runtime-based solutions. Otherwise, IDisposable + finalizers generally presents a good enough solution on its own.

[AaronRobinsonMSFT]

Do we have the same object-identity problems with Swift that we have with COM/WinRT/Objective-C?

I would imagine so. Users are going to use dictionaries in their UI applications. I can't imagine being able to handle everything with IDisposable, unless we narrow the scenarios we'd like to support.

[kotlarmilos]

Is this meant to mean managed instances of a Swift type or projection of the concept, akin to instances of System.Type?

This refers to managed instance of a Swift type that user interacts with.

What are these challenges? Is the problem that IDispose on every type leads to too verbose code that the users have to write?

I see a potential burden on users with nested types, where the user would need to implement IDisposable and correctly release memory within nested types.

I would imagine so. Users are going to use dictionaries in their UI applications. I can't imagine being able to handle everything with IDisposable, unless we narrow the scenarios we'd like to support.

Can you provide some examples where IDisposable can't be used?

[kotlarmilos]

I updated the docs to reflect provided feedback. We can proceed with IDisposable and eventually review this at some later stage.

[kotlarmilos]

Let's review it at a later stage when structs and classes are introduced. Since this is a minor change, please let me know if you'd like to merge it now or prefer to close this PR.

[kotlarmilos]

More details added in #312 (comment). Closing this PR.