[SwiftBindings] Add array support

[stephen-hawley]

This pull request adds a binding for Swift.Array.

This binding demonstrates a fundamental difference between the design of core types in Swift vs. .NET.
Swift uses consistent "copy on write" semantics for pretty much everything. This means that if you write this in Swift:

var a1:[Int] = [1, 2, 3]
var a2:[Int] = a1
a2[0] = 17
print(a1[0])
print(a2[0])

you will see

1
17

This is clearly not what a C# developer would expect and as such this binding doesn't reflect that. Any operation that mutates an instance of the array will effectively throw away the old instance which isn't precisely ideal, but here we are.

This is another example of a generic binding but this is different from SwiftOptional in that there are two types of methods: non-mutating (ie, normal methods) and mutating methods. These have very different calling conventions.

For non-mutating methods, the instance gets passed in as the first argument (not using the self register) and the type metadata of the generic parameter gets passed in.
For mutating methods, a pointer to a copy of the instance gets passed in in the self register and the type metadata of the array gets passed in.

Like many Swift primitives, this type is...unusual. I think it's technically a value type (it sure is acting like one), but under the hood the actual implementation may be one of several types. As a default, it looks like it's an NSArray for most cases.

Question: should I include an IDisposable implementation here or do we want to put that into a common base class?

[matouskozak]

Based on https://developer.apple.com/documentation/swift/array, array is a @frozen generic struct. Do we plan to remove this projection code (SwiftArray.cs) when the tooling is able to successfully project any @frozen generic struct or is the plan that selected Swift types have special projections like this?

I'm just curious about the long-term plan. I think it makes sense for these "often-used" types to have special projections if they need to be handled with caution to satisfy both Swift constraints and .NET developers.

[kotlarmilos]

How memory is handled? Who owns the memory?

[kotlarmilos]

Question: should I include an IDisposable implementation here or do we want to put that into a common base class?

I wouldn't include it unless it's actually used. Let's review the UX at some point (added to the plan).

[kotlarmilos]

Could you add the manual bindings to the type database xml?

[jkurdek]

Array conforms to a bunch of protocols in Swift. Assuming that we would like to have protocol constraints projected as generic constraints on c# side, how are we gonna make this work?

E.g. to call https://developer.apple.com/documentation/storekit/product/products(for:) with SwiftArray we will need to be able to somehow model Collection<T> conformance

[kotlarmilos]

E.g. to call https://developer.apple.com/documentation/storekit/product/products(for:) with SwiftArray we will need to be able to somehow model Collection conformance

Do we need to model Collection<T> for this use-case? Is this requirement applied to the method where the conformance is needed? Is the conformance already available in the dynamic library?

[jkurdek]

I think it depends on how we want the projection to look like.

The pattern used by `products(for:) calls for something like this (I skip async)

public Product products<T> (T identifiers) where T : ICollection<Swift.String>

I guess we could not map ICollection into c#, and have

public Product products<T> (T identifiers)

but then we would have to hardcode some stuff:

• assumption that anything which goes into the function is valid
• we would still somehow need to obtain the protocol conformance descriptor and PWT

[kotlarmilos]

assumption that anything which goes into the function is valid

I would assume the input is valid until focus on protocols support.

we would still somehow need to obtain the protocol conformance descriptor and PWT

Since the protocol's mangled name and generic type are known at runtime, can we retrieve the conformance using Swift runtime API?

[jkurdek]

Should this be public?

[jkurdek]

I think a bit less confusing order would be SwiftHandle handle, nint index, TypeMetadata elementMetadata, SwiftSelf self. Current version will compile anyway as self will go into register and be removed from parameter list before the call, but I think it would be nice to stay consistent with how this looks in llvm-ir where self is the last parameter. (we enforce that for SwiftSelf<T> as well) Also applies to others.

[jkurdek]

For non-mutating methods, the instance gets passed in as the first argument (not using the self register) and the type metadata of the generic parameter gets passed in.

The mutating functions look as expected, but the non-mutating are truly interesting. Her a pointer to the copy is technically the second argument. This is something that generated projections would get terribly wrong. Is there any common pattern to the functions which behave like this on other types? Or each case requires manual investigation?

[kotlarmilos]

There is "funcSelfKind": "NonMutating" property in the ABI.

[kotlarmilos]

Closing this PR in favour of #2964.