C++ Interop should not require "type alias"es for `std::span` <-> `Span` conversions

[MahdiBM]

Motivation

See this forums thread for how I found out about this: https://forums.swift.org/t/making-simdutf-c-c-seamlessly-interoperate-with-swift/83940/4

The issue is, you are REQUIRED to use a "typealias" for std::span and Span to work seamlessly.
So this works:

using char16_span = std::span<const char16_t>;

bool validate_utf16_as_ascii(char16_span input __noescape);

But this doesn't

bool validate_utf16_as_ascii(std::span<const char16_t> input __noescape);

This is suboptimal as it means the libraries adopting Swift's C++ interop might need some more changes for Swift to synthesize Swift-Span functions.

So 1- you need to adopt __noescape, and 2- you need to use "typealias"es.

This makes it harder for C++ libraries to just "plug in" Swift support.

Proposed solution

I think Optimally Swift just creates those "type alias"es by iteself.

Like if it sees a std::span<const char16_t>, it automatically creates a using std_span_of_const_char16_t = std::span<const char16_t> for it.
But then it'll need to always do this to ensure backward compat will not break if the library adopts using using by itself.

Or maybe the compiler can simply just synthesize functions that use Spans if it sees a C++ function using std::span __noescape.

Also the docs / the WWDC video could have been more clear about the fact that this is required, not optional.

Alternatives considered

No response

Additional information

No response

[hnrklssn]

This is a limitation in C++ interop, where the Swift side currently cannot instantiate templated types. This is needed in the generated wrapper function to construct the parameter to forward to the underlying function.

I agree that the current limitation is suboptimal, and synthesizing a type alias is a reasonable way forward.

But then it'll need to always do this to ensure backward compat will not break if the library adopts using using by itself.

I don't know that we are willing to commit to always doing this, but then again I'm not sure that I agree that this source stability is necessary. If a library manually went from using using std_span_of_const_char16_t = std::span<const char16_t> to using SpanConstChar16 = std::span<const char16_t> there would be no expectation that this wouldn't be a source break for clients using std_span_of_const_char16_t.

Or maybe the compiler can simply just synthesize functions that use Spans if it sees a C++ function using std::span __noescape.

I'm not sure I follow what the difference is here.

[MahdiBM]

@hnrklssn In the source-compat statement, I meant that if the compiler is creating its own using whatever = std::span<...>, then it needs to always generate that even if the project after a while moves to using using whetever_else of their own.

Imagine this:

If today we have:

void doSomething(std::span<...> param __noescape)

I was suggesting that swift itself can think of this as this other code, and generate code for that:

using whatever = std::span<...>

void doSomething(whatever param __noescape)

In this case, if tomorrow the C++ library changes to have:

using whatever_else = std::span<...>

void doSomething(whatever_else param __noescape)

Then there would be a whatever type that swift is no longer conjuring, and thus user code could break.

So the solution to this would have been for Swift to if it sees the following:

using whatever_else = std::span<...>

void doSomething(whatever_else param __noescape)

It not only creates the related stuff for whatever_else, but also conjures a whatever just to ensure there are no source-compat breakage concerns.

That is, of course, if this path is chosen by the Swift compiler at all.