[Requirement Machine] Implement same-element requirements.

[simanerush]

Resolves rdar://131630764.

This is the continuation of the original PR #67465 since I hope to fix the CI errors to be able to land the changes.

• Fix CI errors
• Address review feedback
• Support concrete same-type requirements?

From the original PR:
SE-0393 supports same-element requirements. From the proposal:

A same-type requirement where one side is a type parameter pack and the other type is a scalar type that does not capture any type parameter packs is interpreted as constraining each element of the replacement type pack to the same scalar type:

func variadic<each S: Sequence, T>(_: repeat each S) where repeat (each S).Element == T {}

This is called a same-element requirement.

We represent pack elements in the requirement machine through a new singleton PackElement symbol, written [element]. Same-element requirements are mapped to re-write rules that prefix type parameter pack terms with the [element] symbol.

For example, given a protocol P with an associated type A, the generic signature <each T, U> where repeat each T: P, repeat (each T).A == U maps to the following re-write system:

Rewrite system: {
- [P].[P] => [P]
- [P].A => [P:A]
- [P].[P:A] => [P:A]
- [P:A].[shape] => [shape]
- τ_0_1.[shape] => [shape]
- each τ_0_0.[P] => each τ_0_0
- [element].each τ_0_0.A => τ_0_1
- each τ_0_0.A => each τ_0_0.[P:A]
- [element].each τ_0_0.[P:A] => τ_0_1
- [element].each τ_0_0.[shape] => [shape]
}

The implementation is gated behind -enable-experimental-feature SameElementRequirements because the minimal conformance computation doesn't yet support same-element requirements. The current rewrite rules also do not support deriving pack element conformance from a scalar type parameter conformance through same-element requirements. For example, the generic signature <each T, U> where U: P, repeat each T == U maps to the following rewrite system:

Rewrite system: {
- [P].[P] => [P]
- [P].A => [P:A]
- [P].[P:A] => [P:A]
- [P:A].[shape] => [shape]
- τ_0_1.[shape] => [shape]
- τ_0_1.[P] => τ_0_1
- [element].each τ_0_0 => τ_0_1
- τ_0_1.A => τ_0_1.[P:A]
}

The conformance rule τ_0_1.[P] => τ_0_1 and the same-element rule [element].each τ_0_0 => τ_0_1 do not provide a rewrite path to the pack conformance rule each τ_0_0.[P] => each τ_0_0. One possible solution is to use element symbols for all property rules, which would also allow the minimal conformance support to fallout naturally. However, this approach poses a problem for same-type-pack requirements. If we use [element] symbols for same-type-pack requirements, e.g. [element].each τ_0_0 => [element].each τ_0_1, then this rule no longer implies a same-shape rule each τ_0_0.[shape] => each τ_0_1.[shape]. Stripping the [element] symbols from same-type-pack rewrite rules creates a different set of problems for conformances, because the pack conformance rules contain [element] symbols, which would prohibit applying associated type rewrite rules to non-element pack terms. I'm still exploring strategies for resolving these issues, hence the experimental flag!

[simanerush]

@swift-ci please clean smoke test

[martialln]

Thank you for continuing the work on this feature !

Does this PR will also allow construct like this:

protocol P {
    associatedtype A
}
struct Foo<each T> {
    func bar<each S: P>(s: repeat each S) 
        where repeat (each S).A == each T /* or something like (repeat (each S).A) == (repeat each T)*/ 
    { /**/ }
}

?

[simanerush]

@martialln Yes, this construct will be allowed🙂

[simanerush]

@swift-ci Please smoke test

[AnthonyLatsis]

@swift-ci Please smoke test macOS

[shaps80]

Amazing to see this making progress. Just curious when we might see this available? Thanks!

[simanerush]

@shaps80 Currently, this implementation is missing concrete same-element requirements, and unfortunately I can't provide an estimate of when this will be ready.
cc @slavapestov

[shaps80]

Ok fair enough. Thanks for letting me know

[Lancelotbronner]

Will this be part of Swift 6?

[vanvoorden]

struct Variadic<each T> {}

extension Variadic where T == {Int, String} {} // {Int, String} is a concrete pack

extension Variadic where T == Never {} // client passed no parameter pack

Hi! I'm looking for (someday in the future) using something like this to enable an "optional" parameter pack. Do we think this diff would also implement the "Explicit type pack syntax" from SE-0393¹ or would that land in another diff? Thanks!

Footnotes

1. https://github.com/swiftlang/swift-evolution/blob/main/proposals/0393-parameter-packs.md#explicit-type-pack-syntax ↩

[simanerush]

@swift-ci please smoke test

[simanerush]

@swift-ci please smoke test

[simanerush]

@swift-ci please smoke test

[simanerush]

@swift-ci please smoke test macOS

[simanerush]

@swift-ci please smoke test

[dehesa]

We are hitting this limitation constantly at raycast. We would jump of joy if it could reach Swift 6 by this September 😆

In any case, thank you for working on this.

[hborla]

We are hitting this limitation constantly at raycast. We would jump of joy if it could reach Swift 6 by this September

This change will not be included in Swift 6. I understand that people are hitting this limitation frequently and would like for it to be lifted, but there are still open technical challenges with this change. As noted in the PR description, the implementation is gated behind an experimental flag because there are issues with how same-element requirements are represented that we're not happy with. These issues impact the user-facing semantics; they're not just implementation challenges.

[hborla]

@swift-ci please smoke test

[dehesa]

I see! Thank you for the openness and setting expectations. I am sad to hear it won’t be there for Swift 6, but if it is not ready, it is not ready 😅
I just wanted to express my strong interest in this feature and my love for the new variadic generics.

[slavapestov]

@simanerush IMO we should merge this with the user-visible requirement desugaring change behind an experimental flag.