Review UX and bindings for .NET Swift interop tooling in simple P/Invoke void cases

[kotlarmilos]

Description 

This issue is intended to discuss the user experience and bindings generated by the Swift bindings tooling available at dotnet/runtimelab#2517. The focus is on evaluating the quality of the generated C# code, scalability and trimming, and the overall UX experience.

Usage

Example usage:

dotnet SwiftBindings.dll -d "./libHelloLibrary.dylib" -s "./HelloLibrary.swiftinterface" -o "./"

Options:

  -d, --dylibs             Required. Paths to the dynamic libraries (dylibs), separated by commas.
  -s, --swiftinterfaces    Required. Paths to the Swift interface files, separated by commas.
  -o, --output             Required. Output directory for generated bindings.
  -h, --help               Display this help message.
  --version                Display version information.

When an unknown type is encountered, the tooling will report the error and proceed with bindings generation.

Simple binding

The supported scenario involves simple P/Invoke calls without arguments and with a void return type.

Swift library:

public func sayHello() {
    print("Hello world")
}

Generated C# bindings:

using System;
using System.Runtime.InteropServices;
namespace HelloLibrary
{
    public class TopLevelEntities
    {
        public static void SayHello()
        {
            NativeMethodsForTopLevelEntities.PIfunc_SayHello();
        }
    }
    internal class NativeMethodsForTopLevelEntities
    {
        [DllImport("libHelloLibrary.dylib", EntryPoint = "$s12HelloLibrary03sayA0yyF")]
        internal static extern void PIfunc_SayHello();
    }
}

User's C# code:

using System;
using HelloLibrary;

namespace HelloWorld
{
    public class Program
    {
        public static void Main(string[] args)
        {
            TopLevelEntities.SayHello();
        }
    }
}

/cc: @stephen-hawley @AaronRobinsonMSFT @vitek-karas

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description 

This issue is intended to discuss the user experience (UX) and bindings generated by the Swift bindings tooling available at https://github.com/dotnet/runtimelab/tree/swift-bindings/basic-tooling. The focus is on evaluating the quality of the generated C# code, scalability and trimming, and the overall UX experience.

Usage

Example usage:

dotnet SwiftBindings.dll -d "./libHelloLibrary.dylib" -s "./HelloLibrary.swiftinterface" -o "./"

Options:

  -d, --dylibs             Required. Paths to the dynamic libraries (dylibs), separated by commas.
  -s, --swiftinterfaces    Required. Paths to the Swift interface files, separated by commas.
  -o, --output             Required. Output directory for generated bindings.
  -h, --help               Display this help message.
  --version                Display version information.

When an unknown type is encountered, the tooling will report the error and proceed with bindings generation.

Simple binding

The supported scenario involves simple P/Invoke calls without arguments and with a void return type.

Swift library:

public func sayHello() {
    print("Hello world")
}

Generated C# bindings:

using System;
using System.Runtime.InteropServices;
namespace HelloLibrary
{
    public class TopLevelEntities
    {
        public static void SayHello()
        {
            NativeMethodsForTopLevelEntities.PIfunc_SayHello();
        }
    }
    internal class NativeMethodsForTopLevelEntities
    {
        [DllImport("libHelloLibrary.dylib", EntryPoint = "$s12HelloLibrary03sayA0yyF")]
        internal static extern void PIfunc_SayHello();
    }
}

User's C# code:

using System;
using HelloLibrary;

namespace HelloWorld
{
    public class Program
    {
        public static void Main(string[] args)
        {
            TopLevelEntities.SayHello();
        }
    }
}

Author:	kotlarmilos
Assignees:	kotlarmilos
Labels:	design-discussion, area-Meta
Milestone:	9.0.0

[jkotas]

@kotlarmilos It looks odd to have the code in one repo and the issues in a different repo. Would it make sense for the Swift interop issues to live in runtimelab, next to the code?