Simplify importing Swift into .NET; instead of tool details outline t…

…he flow with artifacts

proposed/swift-interop.md

@@ -158,19 +158,13 @@ The projection tooling should be split into these components.
 
 ##### Importing Swift into .NET
 
-Importing Swift into .NET is done through bindings generated by the following components:
- - `Demangler`: This component analyzes a source Swift library and maps entry points to mangled names. It consumes a source Swift library and creates `TLDefinition` objects that contain type, mangled name, demangled name, module name, and offset within a module.
- - `Swiftmodule parser`: This component aggregates the public API. It takes in a `.swiftmodule` file generated by the Swift compiler, similar to a C header file, and combines it with the `TLDefinition` objects to generate a module declaration.
- - `WrappingCompiler` and `OverrideBuilder`: These components generate Swift wrappers for cases where direct P/Invoke from C# into Swift is not possible.
- - `NewClassCompiler`: This component generates C# bindings based on the generated `TLDefinition` and module declarations. It should implement type mapping and register lowering. Key considerations include:
-   - Splitting out tuples into individual parameters
-   - Determining the return buffer size using the value witness table for the struct type
-   - Managing enum/struct arguments through registers vs. passing by reference
-   - Error handling
- - `XamGlue`: This component is a library that provides basic support for Swift interop that the generated code builds on. It includes bindings for common built-in types like arrays and dictionaries. It provides a single source of truth for Swift types so that they can be exposed across an assembly boundary. This can be a NuGet package, possibly referencable by `FrameworkReference` or automatically included when targeting macOS, Mac Catalyst, iOS, or tvOS platforms that exposes the platform APIs for each `.framework` that is exposed from Swift to .NET.
- - `Tom-Swifty`: This component orchestrates other components and allows users to easily generate Swift projections for a given set of `.framework`s. It presents an interface on top of the tool that is user-friendly and project-system-integrated.
-
-The flow starts with the source Swift library, which is processed by the Demangler to generate `TLDefinition` objects. Then, the `Swiftmodule parser` aggregates the public API from `.swiftmodule` file and generates a module declaration. Both the `TLDefinition` objects and module declaration are then used as inputs for two distinct components: the `WrappingCompiler` and `OverrideBuilder`. These components generate Swift wrappers source code. The wrappers source code is subsequently processed again by the `Demangler` and `Swiftmodule parser` leading to the generation of wrapper library `TLDefinition` objects and its module declaration. Finally, `TLDefinition` and module declarations, both for the source Swift library and Swift wrappers, are consumed by the `NewClassCompiler` to generate C# bindings.
+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.
 
 ##### Exporting .NET to Swift
 
@@ -187,7 +181,7 @@ For a C# class that can be inherited gets implemented in C#, the tool generates
 
 ### Distribution
 
-The calling convention work will be implemented by the .NET runtimes in dotnet/runtime. 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.
+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.
 
 ### Validation