[SR-1445] Recursive protocol constraints

[hartbit]

Previous ID	SR-1445
Radar	rdar://problem/20531108
Original Reporter	@hartbit
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	7
Component/s	Compiler
Labels	Bug
Assignee	@DougGregor
Priority	Medium

md5: 4b84506f25ece4c8bff8423d20b24de5

blocks:

• SR-3454 Eliminate _IndexableBase protocol

is duplicated by:

• SR-5479 protocol associatedtype where-clause rules not consistent with direct colon constraint rules

relates to:

• SR-6225 Swift compiler crashes if two protocols refer the type of each other spreat around diffenrent files.
• SR-4979 SubSequence is not a Sequence, can't be zipped?

Issue Description:

From the Generics Manifesto:

Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library SubSequence type of a Sequence should itself be a Sequence:

protocol Sequence {
  associatedtype Iterator : IteratorProtocol
  ...
  associatedtype SubSequence : Sequence   // currently ill-formed, but should be possible
}

The compiler currently rejects this protocol, which is unfortunate: it effectively pushes the SubSequence-must-be-a-Sequence requirement into every consumer of SubSequence, and does not communicate the intent of this abstraction well.

[jadengeller]

Will implementation of this feature allow for instantiation of structs that add a recursive protocol constraint? i.e.

protocol Wrapper { associatedtype Wrapped }
indirect enum Foo<Bar: Wrapper> where Bar.Wrapped == Foo { case bar(Bar) }

This code currently compiles, but it is impossible to create an instance of `Foo` since you cannot write a type that is parameterized by itself. I guess I would also expect recursive typealiases to work as well.

typealias FooFix = Foo<FooFix?> // assuming Optional: Wrapper

[davidbjames]

What is the status on this? Seems a critical piece to the generic puzzle. 🙂

Code from a library I'm writing:

public protocol QueryBridgeable  {
    
    associatedtype Base = Self where Base : Queryable & QueryBridgeable
    
    var query:QueryFactory<Base> { get } // Error "'query' used within its own type"
    func query(_ options:SubQueryOptions) -> QueryFactory<Base>
}

All items that are "query bridgeable" should be able to generate ("query") items that are themselves "query bridgeable" so they have access to the same interface.

[DougGregor]

Still working on it, but getting a whole lot closer!

[davidbjames]

Go Doug Go!! 🙂

[Moximillian]

@davidbjames is there a reason why this wouldn't work for you?

public protocol QueryBridgeable  {
  var query: QueryFactory<QueryBridgeable & Queryable> { get }
  func query(_ options: SubQueryOptions) -> QueryFactory<QueryBridgeable & Queryable>
}

[DougGregor]

I'm going to mark this as "done" for now. While there are some known bugs (including non-trivial ones!), we've rolled out the feature in the standard library and developers should be able to use it in Swift 4.1.