# Pitch: Protocols with private fields

**URL:** <https://forums.swift.org/t/pitch-protocols-with-private-fields/51209>\
**Category:** Pitches\
**Created:** [August 14, 2021, 11:45am UTC](https://forums.swift.org/t/pitch-protocols-with-private-fields/51209 "2021-08-14T11:45:03Z")\
**Posts on this page:** 1\
**Showing post:** 22

<div class="post-metadata">

**Author:** ![Alvae](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alvae/32/37012_2.png) [@Alvae](https://forums.swift.org/u/Alvae)\
**Post date:** [December 6, 2021, 1:07pm UTC](https://forums.swift.org/t/pitch-protocols-with-private-fields/51209/22 "2021-12-06T13:07:09Z")

</div>

Actually I'll side with @dabrahams and @xwu on that matter. Their example is indeed one way to implement my use case. Although `QImpl` has to be exposed, crucially, the implementation details brought by `QImpl` are **not** exposed by the conforming type.

The approach proposed in this pitch is to completely encapsulate an implementation from the outside. From the perspective of a type consumer, though, that's a distinction without a difference. Further, as suggested by @dabrahams, scoped conformance would allow a library to vend multiple implementations for the same protocol.

```swift
// In module A
protocol P {}
protocol PImplA: P { ... }
protocol PImplB: P { ... }

// In module B
struct S: P, private: PImplA { ... }
struct T: P, private: PImplB { ... }

```

Here, both `B.S` and `B.T` conform to `A.P`, but they use two different implementations defined in module `A`.

I disagree with @dabrahams on a couple of points though:

> [@dabrahams](#):
>
> The protocol system would retain its simplicity

Scoped conformance have their own subtleties. For instance, dynamic dispatch resolution is a rather significant one. In particular, I am worried about that sentence:

> [@Scoped Conformances](https://forums.swift.org/t/scoped-conformances/37159/1):
>
> Our answer is that X’s conformance (or not) to P is captured in the scope where the X value is first converted to an existential type.

The post ends with a handful of other difficult questions. Generally, it seems like dealing with multiple conformance and conformance inheritance will compel us to come up with new rules.

Although I don't claim such mechanisms cannot be designed or understood, having [formalized](https://dl.acm.org/doi/10.1145/3426425.3426939) and [partially reimplemented](https://github.com/val-lang/val) Swift's _current_ method resolution I'd argue that it's definitely not "simple".

> [@dabrahams](#):
>
> A protocol would have a single, well-understood meaning that doesn't change across access levels

My pitch does not challenge that assertion. A protocol would describe a single, well-understood API with the addition be that access levels would be part of that API.

> [@dabrahams](#):
>
> We'd avoid adding another language feature, since I believe we [need scoped conformances](https://forums.swift.org/t/improving-sendable/52377/22) anyway.

While I adhere wholeheartedly to the principle of "economy of concept", I'd like to point out that the setup for implementing my use case with scoped conformance is more involved and feels a little like a "trick".

I'd be interested to discuss things the other way around. What use case solved by scoped conformance cannot be solved by access lower bounds?

---

_[View the full topic](https://forums.swift.org/t/pitch-protocols-with-private-fields/51209)._