Avoid tool details and add limitations

Author: kotlarmilos

proposed/swift-interop.md

@@ -160,11 +160,11 @@ The projection tooling should be split into these components.
 
 Importing Swift into .NET is done through the following steps:
 
-1. The tool analyzes a source `.swift` library and maps entry points to mangled names.
-2. Then,the tool aggregates the public API; it takes in a `.swiftmodule` file (similar to a C header file) generated by the Swift compiler, creating a module declaration.
-3. For cases where direct P/Invoke from C# into Swift is not possible, the tool generates `.swift` source code wrappers along with a `.dylib` compiled native library.
-4. Subsequently, the tool aggregates the public API and generates module declarations for the generated wrappers.
-5. Finally, the tool generates C# bindings in the form of a `.dll` assembly based on the generated module declarations.
+1. The tool analyzes a source library `.swift` and maps entry points to mangled names.
+2. Then, the tool aggregates the public API; it take in a `.swiftmodule` file (similar to a C header file) generated by the Swift compiler.
+3. For cases where direct P/Invoke from C# into Swift is not possible, the tool generates source code `.swift` wrappers and compiles them.
+4. Subsequently, the tool aggregates the public API for the generated wrappers.
+5. Finally, the tool generates C# bindings source code based on the aggregated public API and compiles them.
 
 ##### Exporting .NET to Swift
 
@@ -179,6 +179,13 @@ If we were to use an IL-post-processing tool here, we would break Hot Reload in
 
 For a C# class that can be inherited gets implemented in C#, the tool generates a mirror class in Swift and overrides it with another class that vectors all the calls through a simulated vtable. This class implements the constructor and overrides the virtual methods by sending calls to a function pointer which ends up in C#.
 
+##### Limitations of the tool
+
+The current version of the projection tooling has limitations and, in some cases, requires Swift wrappers in addition to C# bindings. Here are some examples:
+1. Passing a struct by value in more registers than P/Invoke will allow. In this case, it requires "unpacking" from the Swift side.
+2. Exporting .NET types into Swift.
+3. Handling closures.
+
 ### Distribution
 
 The calling convention work will be implemented by the .NET runtimes in [dotnet/runtime](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/Swift/SwiftTypes.cs). The projection tooling will be implemented and shipped as part of the Xamarin publishing infrastructure. The projection tooling will be accessible as a .NET CLI tool and distributed as a NuGet package. It should either be automatically included as part of the TPMs for Apple platforms or should be easily referencable.