Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-1445] Recursive protocol constraints #44054

hartbit opened this issue May 8, 2016 · 6 comments

[SR-1445] Recursive protocol constraints #44054

hartbit opened this issue May 8, 2016 · 6 comments


Copy link

@hartbit hartbit commented May 8, 2016

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


  • 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.

Copy link

@jadengeller jadengeller mannequin commented May 8, 2017

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

Copy link

@davidbjames davidbjames commented Jul 28, 2017

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.

Copy link

@DougGregor DougGregor commented Aug 1, 2017

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

Copy link

@davidbjames davidbjames commented Aug 2, 2017

Go Doug Go!! 🙂

Copy link

@Moximillian Moximillian commented Sep 25, 2017

@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>

Copy link

@DougGregor DougGregor commented Nov 2, 2017

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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants