# Some thoughts on the proliferation of Sendable

**URL:** <https://forums.swift.org/t/some-thoughts-on-the-proliferation-of-sendable/68114>\
**Category:** Discussion\
**Tags:** concurrency\
**Created:** [October 27, 2023, 9:27pm UTC](https://forums.swift.org/t/some-thoughts-on-the-proliferation-of-sendable/68114 "2023-10-27T21:27:47Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [October 29, 2023, 10:46pm UTC](https://forums.swift.org/t/some-thoughts-on-the-proliferation-of-sendable/68114/12 "2023-10-29T22:46:30Z")

</div>

> [@jrose](#):
>
> “Almost everywhere” is a really strong statement for a language with first-class classes, Any, and UnsafePointer.

let’s go through these exceptions one by one.

### UnsafePointer

`UnsafePointer` is a textbook example of an unsafe construct that gets wrapped by some “safe” abstraction which is ostensibly `Sendable`, but only because the lax concurrency mode doesn’t require the wrapper type to only contain `Sendable` stored properties.

under the strict concurrency mode, it raises warnings because the wrapped pointer is not `Sendable` ([SE-0331](https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md)).

but such a type would usually still carry a

```swift
@available(*, unavailable, message: "not Sendable because ...")
extension PointerWrapper:Sendable

```

to document why it is not `Sendable`, and to force the warning to appear even with the lax concurrency mode.

this isn’t a very common case, it’s just an example of a place where being able to write `PointerWrapper:~Sendable` would be helpful.

### Any

`Any` is already a problem when using the strict concurrency mode, it inevitably needs to be refactored into `any Sendable` in code that uses concurrency. `Any` without any `Sendable` qualifications just isn’t that useful in a concurrent context.

this is a weird inverse of the problem we have with `~Copyable` and `Any`, and you could imagine an alternate reality where `Any` didn’t imply `Copyable` and we had a similar problem with underconstrained existentials that cannot be copied.

### Classes

i personally think classes with mutable state are going to become an endangered species as the strict concurrency mode becomes more popular, they just don’t compose very well with concurrency.

for a concrete case study, you can browse through some of [the discussions](https://forums.swift.org/search?q=ClientBootstrap) about SwiftNIO’s `ClientBootstrap` class, which was conceived before the language had first-class concurrency support, and is now widely viewed as ill-adapted for modern concurrency features.

> [@Creating many “clients” vs wrapping a “client” in an actor](https://forums.swift.org/t/creating-many-clients-vs-wrapping-a-client-in-an-actor/67380/2):
>
> I just stumbled over the very same annoyance of the `ClientBootrap` not being sendable - including the same thought process about using an actor being overkill.

> [@Creating many “clients” vs wrapping a “client” in an actor](https://forums.swift.org/t/creating-many-clients-vs-wrapping-a-client-in-an-actor/67380/3):
>
> We've got tentative plans to deprecate-and-replace the current bootstraps, because they aren't really serving their purpose well anymore. In particular the builder pattern has aged poorly. The next versions will likely be value types, which makes this entire problem go away.

> [@Why isn’t \`ClientBootstrap\` \`Sendable\`?](https://forums.swift.org/t/why-isn-t-clientbootstrap-sendable/62577/4):
>
> You are right, `ClientBootstrap` should have been a struct. Sadly we can't change this without breaking API. Note that this would need some more redesign in the current implementation but AFAIK nothing fundamentally impossible in a new major version.

i personally think a lot (not all, but a lot) of these types will have to evolve into actors if they need shared state, and structs/enums otherwise.

### conclusion

i don’t think these exceptions really contradict my argument that `Sendable` is too fundamental a conformance to have to be sprayed everywhere preemptively, or reported as an issue when it is missing. the types that are `~Sendable` are the special cases, and i think as the warnings pile up they are going to become less common and the ones that remain will become more-clearly documented as such.

---

_[View the full topic](https://forums.swift.org/t/some-thoughts-on-the-proliferation-of-sendable/68114)._