Is this behaviour of Protocol Static Member Lookup intentional

Using Swift
,
12

The only possible reason to allow this is if types could be nested within protocols. Then you could have namespace chains. (All of the namespaces could be nested inside of one protocol adopter.) There is no use case for non-nested static members with differing types to use leading dot syntax.

What we have right now is nonsense, inconsistent with the non-protocol version of the same idea:

struct Example<T> {
  enum Namespace { }
}

extension Example<String> {
  static var matchingExample: Example { .init() }
  static var nonMatchingExample: Example<Int> { .init() }
}

extension Example.Namespace {
  static var stringExample: Example<String> { .init() }
  static var intExample: Example<Int> { .init() }
}

func accept(_: Example<some Any>) { }

// All compile.
accept(.matchingExample)
accept(.Namespace.stringExample)
accept(.Namespace.intExample)

// ❌ Member chain produces result of type 'Example<Int>' but contextual base was inferred as 'Example<String>'
accept(.nonMatchingExample)

Edit:

It's not as bad as I thought—namespacing is possible, with a type alias. There's just currently no point in defining it anywhere but in the constrained protocol extension, because autocomplete doesn't pick it up in any case whatsoever—which is a bug not present in the above, generic form.

protocol Example { }

extension String: Example { }
extension Int: Example { }

enum _Namespace: Example { }

extension Example where Self == String {
  static var matchingExample: Self { .init() }
  static var nonMatchingExample: Int { .init() }
  typealias Namespace = _Namespace
}

extension Example.Namespace {
  static var stringExample: String { .init() }
  static var intExample: Int { .init() }
}

func accept(_: some Example) { }

// All compile.
accept(.matchingExample)
accept(.Namespace.stringExample)
accept(.Namespace.intExample)
accept(.nonMatchingExample)