Protocol Witness Matching Mini-Manifesto

Evolution Discussion
21

The introduction section already has a few examples (see the doc here: [Docs] Add the Protocol Witness Matching mini-manifesto by theblixguy · Pull Request #29617 · apple/swift · GitHub) but I could add this as well.

22

I have added it now!

1 Like
23

Its nice. Thank you.

1 Like
24

@suyashsrijan one alternative to properties with function type would be to just allow functions and variables interchangably for functions with no parameters. I.e. the following would build with no error.

protocol One {
  var integer: Int { get }
}

class Alpha: One {
  func integer() -> Int {
    return 1
  }
}

protocol Two {
  func integer() -> Int
}

class Bravo: Two {
  var integer: Int {
    2
  }
}
1 Like
25

I see the PR is still active, so I'm reviving the conversation.

Now with SE-302 introducing @unchecked conformances, would it be feasible to say any @unchecked conformance possibly falls back to a @dynamicMemberLookup method dispatch and be the protocol witness that way? or was it meant for a totally different context?

I can imagine this being useful for a test mocking/stubbing library, where you can conform a Stub class with @unchecked conformace to an existing protocol, so it can adopt any protocol with ease via its subscript

extension Stub: @unchecked SomeExistingProtocol {
    subscript<T>(dynamicMember member: String) -> T { ... }
}
26

I understand the review of the PR has paused for a while. I just would like to bring up another mismatching scenario that isn't mentioned in the doc and is probably worth considering.

protocol Proto {
    var x: Int? { get }
}

struct Test: Proto {
    var x: Int
}

In my opinion this example meets the following criteria of the doc perfectly:

it should be based on what the protocol requirement semantically requires.

I think supporting the above example helps to remove boilerplate code (though I have no idea how complex it would be to add support for it).