1

In attempting to adopt the new static member lookup introduced in SE-0299 / Swift 5.5, I've run into a limitation and I'd like to know whether it's intentional or just an implementation issue.

Say I have a protocol hierarchy:

protocol A {}
protocol B {}
protocol C: A & B {}

I can create types which conform to C and use them wherever I use A or B, as much of the implementation is the same between conformances. However, under the new syntax, if I extend C to add the static members, those members aren't visible at A or B use sites. Given that I can use the actual C-conforming values at those locations, shouldn't I be able to use the static members as well? Is this limitation intentional?

1 Like
2

I read your message twice to make sure I follow it. Counter question: why do you expect a static member, which is introduced in an extension on a sub-type, to become available on the super-type?

As a workaround, you could probably do it in reverse:

extension A where Self: C {
  // add it here
}

I didn't test it but it should be available conditionally on A, but inheritly on C.

1 Like