How best to emulate protocols with private requirements?

Using Swift
1

Swift doesn’t support protocols with greater visibility than their requirements. So what is the best technique available to emulate it?

Here, there are two types, S1 and S2, which are generic over types that conform to a protocol. Everything about that protocol should actually be private, except for its name. All of the types that conform to it are known (E1 and E2, here), and I want to extend each of them, privately, to conform to the protocol that the type within the file is generic over. *

The best I’ve come up with is to raise the visibility of the “private“ requirements, but gate them behind associated types.

protocol InternalProtocol {
  associatedtype S1Private: S1PrivateProtocol
  associatedtype S2Private: S2PrivateProtocol
}

enum E1: InternalProtocol { }
enum E2: InternalProtocol { }

struct S1<Internal: InternalProtocol> {
  static var property: Int { Internal.S1Private.property }
}

protocol S1PrivateProtocol {
  static var property: Int { get }
}

extension E1 {
  enum S1Private: S1PrivateProtocol {
    static var property: Int { 11 }
  }
}

extension E2 {
  enum S1Private: S1PrivateProtocol {
    static var property: Int { 12 }
  }
}
S2 is just like S1 here, for simplicity. Don’t focus on that. 
struct S2<Internal: InternalProtocol> {
  static var property: Int { Internal.S2Private.property }
}

protocol S2PrivateProtocol {
  static var property: Int { get }
}

extension E1 {
  enum S2Private: S2PrivateProtocol {
    static var property: Int { 21 }
  }
}

extension E2 {
  enum S2Private: S2PrivateProtocol {
    static var property: Int { 22 }
  }
}

#expect(S1<E1>.property == 11)
#expect(S1<E2>.property == 12)
#expect(S2<E1>.property == 21)
#expect(S2<E2>.property == 22)

\* What I want that to actually be:

protocol InternalProtocol { }
enum E1 { }

struct S1<Private: S1Private> {
  static var property: Int { Private.property }
}

protocol S1Private {
  private static var property: Int { get }
}

extension E1: S1Private {
  private static var property: Int { 11 }
}
Pitch: Non-Public Protocol Requirements
2

If the purpose is “let people know they’re not supposed to use this”, I would just put an underscore before the requirement name. If the purpose is “actually keep other people from calling this”, you can get away with it by having every requirement take an extra argument whose type only has an internal initializer, so nobody outside your module can actually do it without resorting to shenanigans. If it’s “keep other people from implementing this”, have a requirement that returns such a type.

But yeah, I wish you could have private requirements too. Someone would need to propose it and implement it properly though.

5 Likes
3

That all sounds good too, but as you can see above, the main problem is the namespace pollution that happens when you add requirements to a non-private type in multiple files. I.e. the E enums will each have two competing definitions for property without the associatedtype namespaces.

4

@Jrose, @Danny, please help me understand why this feature would be desirable, with a concrete example if possible.

I am no Swift expert, but I thought the whole point of a protocol in Swift was to specify only public requirements. :slight_smile:

1 Like
5

Does S1 need to be public? Would it be an option to expose S1E1 and S1E2 as public wrappers around private S1<E1> and S1<E2> ?

6

Ah, that was not obvious to me, it isn’t in your description at all! Then, yeah, every answer I have is some variation of prefixing or wrapping. :-/

I am somewhat curious what the protocols and concrete types are in your real example, though, because it feels unusual to have two parallel protocols that are basically identical, and also have types that conform to both. Swift not having true generic protocols means this could just be compensating for the code you’d actually like to write, but maybe not?

7

The actual code is basically the following.

A type cannot conform to a protocol in more than one way. So, what is an alternative to this delegating to static members, when you want differing behavior based solely on generic type parameters?

struct S<Phantom: StaticS> { }

protocol StaticS {
  static func f(_: S<Self>)
}

protocol SProtocol {
  func f()
}

extension S<E1>: SProtocol {
  func f() { Phantom.f(self) }
}

enum E1: StaticS {
  static func f(_: S<Self>) { }
}

enum E2: StaticS {
  static func f(_: S<Self>) { }
}
How do you convert a metatype to an existential which references it through a generic type which references it?
Function in generic class extension not called
8

The generic placeholders are injected.

struct Outer<Phantom: StaticS> {
  let inner = S<Phantom>()
}
9

I think in terms of a potential evolution proposal, there are two kinds of "I want private protocol requirements":

  1. "I want to ensure that the complete set of implementors is known" might be expressed as @sealed public protocol P { ... }; the compiler would then refuse to create a conformance to P outside the declaring module. An example use-case might be a database library where the set of primitive column types is fixed.
  2. "I want to have a requirement that can't be called from outside this module, and external conformances must use the default implementation" might be expressed as public protocol P { internal func f() }; extension P { func f() { ... } }. This is "the SwiftUI problem" (where external conformances should provide body, but primitive views need to implement the private _makeViewList function).

Although you can potentially implement 1. using 2. (by not providing a default implementation for an internal requirement), I feel like these are really orthogonal ideas?

2 Likes