SE-0302 (second review): Sendable and sendable closures

The semantics I would expect from @concurrent functions vs @sendable functions
are very similar, but not identical:

@concurrent focuses on the fact that (identical copies of) such functions can be called simultaneously from multiple concurrency domains (actors/executors/threads etc.).

@sendable focuses on the fact that (identical copies of) such functions can be transferred between concurrency domains, but I would not necessarily assume that they can be called when in a different concurrency domain without additional external locking or the guarantee that the function only exists in the current concurrency domain.

Thus I believe @concurrent to be stronger (and possibly strictly stronger) than @sendable.
However, I am uncertain what a correct response to this discrepancy would be.


Generally speaking, pretty nice improvement to original PR.

According to new Sendable @sendable semantics, it'd be better to rename UnsafeTransfer to UnsafeSender - a propertyWrapper of : @unchecked Sendable semantic wrapper.

struct UnsafeSender<Wrapped> : @unchecked Sendable {
  var wrappedValue: Wrapped
  init(wrappedValue: Wrapped) {
    self.wrappedValue = wrappedValue
actor MyAppActor {
  public func doStuff(@UnsafeSender dict: NSMutableDictionary) async

It would be very nice if the core team would define what @uncheck vs checked (example CheckedContinuation ) will mean in Swift. Similarly how it is defined that Unsafe in Swift relates only to memory safety.

Presumably the @unchecked Sendable type will be “checked” for ownership violations?

I’d like to suggest @forced Sendable as an alternative spelling. Reminds me of git force push.

Maybe even @coerced Sendable.

How will protocol inheritance be handled? Let's say I have:

protocol MyProtocol: Sendable {}

Is the following allowed?:

struct MyStruct: @unchecked MyProtocol {}

Or will explicit conformance to the Sendable protocol be required?:

struct MyStruct: MyProtocol, @unchecked Sendable {}

I think the latter is the clearest option.

Edit: I'm explicitly talking about the @unchecked option here. I'm assuming that without @unchecked, conforming to MyProtocol will just imply Sendable.


This reads pretty clearly to me: it's the "sendability" (or, in other words, the semantic validity of conformance to Sendable) that's unchecked. It clearly does not imply that anything else about Swift's rules is unchecked.

UnsafeTransfer is explicitly not a part of this proposal, just included "to illustrate aspects" of future directions, so we don't need to bikeshed the name.


@john_mccall, I think it may be important to add also the following that's mentioned in the document's revision history:

  • Add implicit conformance to Sendable for non-public, non-frozen struct and enum types.

I'd like to briefly focus the review on that point. Specifically, the proposal states:

A struct or enum can only be made to conform to Sendable within the same source file in which the type was defined.

For non-public, non-frozen structs and enums, the Sendable conformance is implicitly provided when conformance checking (described in the previous section) succeeds

I worry that these two rules will not compose well. Library authors who are not fully paying attention to how their value types work with concurrency may find that everything "works fine" only to neglect to vend a checked conformance [e.g., when they extract a type from a working app into a shared library], requiring users to write unchecked retroactive conformances.

I think that if a struct or enum is provably safe to send across concurrency domains, and we buy the justification for implicit conformance for this protocol as opposed to, say, Hashable, then it should apply to public and non-public, frozen and non-frozen structs and enums.

I should raise again the point about considering whether we ought to align with Rust in not conforming the unsafe pointer types to Sendable in the context of this implicit conformance. That would be because structs (and tuples!) that clearly are not safe to conform to Sendable would be implicitly conformed if one of their members is an unsafe pointer.


I feel this should be ok (a more concrete example would be Error). This is not as see-through as we would ideally like, because what's really being unchecked is the conformance to the parent protocol, but if we agree that protocol inheritance is about refining semantics, users should be expected to get acquainted with the new semantics of Error all the way up the inheritance tree.

I'm much happier with the proposal now, especially that authors got convinced to implement @unchecked, which can generally be useful for many other marker protocols in the future (Movable comes to mind).

I still feel that Sendable is kinda too generic of a name, but I yield to the thought that it might be impossible to find a better name that would be equally terse.

I disagree with @xwu's suggestion to allow implicit conformance for public resilient types though. If a library author is not fully paying attention to safety, then someone else should. Explicitly spelling retroactive @unchecked conformance provides much more context, especially that I might imagine that such marker would nudge people towards documenting the decision. I feel that being conservative here will help more users overall.

@unchecked is supposed to mean, “don’t worry, the compiler can’t check but I’ve made sure that it’s safe via internal means.”

A third-party retroactive conformance by construction has no control or sometimes even visibility into how the type is implemented and can’t actually make that guarantee, so whatever the documentation is of that decision, it’s bunk: this would only be a workaround for a missing first-party conformance.

The better solution is to make it easier for first-party authors not to forget that conformance in the first place. For this reason, I argue that implicit conformance should apply to all eligible value types or none, not only a subset of them based on visibility and resilience, which is likely to cause people to forget.


Right, maybe I just haven't shipped or used enough libraries to be able to assess the issue better. I now see how dropping Sendable guarantees could become completely silent for clients if they @unchecked the conformance, while otherwise this would result in a compiler error at least.

I don't know then. I am overall on the side of being more explicit so that the code becomes more self-documenting, but I've also heard Doug's argument on progressive disclosure and boilerplate. Still, Sendable is public API, as much of API as choosing between struct or class, and I don't know if public API should ever be auto-generated.

I still think the implicit conformance could turn out to be a mistake. It will lead to confusing non-local compiler errors. I don't think the annotation is as big a deal as it is being made out to be, at least for application developers, and I'm willing to tolerate some boilerplate in library code.

In practice, application developers will only need to provide a conformance for types they actually need to send across a concurrency boundary. In most well written applications this will be a small portion of the types. Drawing on an example from existing experience, most application code I see does not declare an Equatable conformance if the type does not actually need to be compared in the codebase. To say this another way, just because a valid conformance is possible does not mean it is necessary.

Further, I find the argument that we want to defer the need to learn about Sendable dubious. Swift developers will need to understand at least the basics of its concurrency model and this protocol is a very important brick in the foundation.


To further iterate on this, if we ever find Sendable conformance to be so very burdensome to adopt manually, we always can provide some tooling to walk through the codebase and insert it (maybe that could even be a GSoC project I finally get accepted with lol).

This really will be always tied to the semantics of the type, as much as Equatable or Codable is tied to the intent of being able to equate/encode/decode instances. I don't feel that being concurrency-safe at a specific moment is enough of an indication of the intent to support that at any moment in the future.

1 Like

Since we've already severely limited Sendable's abilities by making it a "marker" protocol, the biggest action-at-a-distance hazard I see with implicit conformances to it is name lookup. If we also say that extension Sendable extensions are not allowed to declare members, that should contain that effect, so that modifying a type's layout does not cause members to flit in and out of existence everywhere else. At that point, I think most of the consequence Sendable conformance appearing or disappearing ought to be contained to first-order "does not conform" errors in call sites that require sendability.

1 Like

I'm referring to a user attempting to send a value across a concurrency boundary and receiving an error because no implicit Sendable conformance was provided. This could be due to a member of a member of a member, i.e. arbitrarily distant from the actual type the user attempted to send. @Chris_Lattner3 and I discussed this in one of the earlier threads.

That's not really any different that the errors users see with automatic Codable or Hashable conformance, so it doesn't seem to make anything worse. Those errors can identify which property of a property (ad infinitum) breaks the conformance, so it should work for this case as well. Improvements to the diagnostic would help in all cases as well.

1 Like

It is actually quite different because Equatable conformance has to be explicitly added so you get the error in the expected location.

I would think the diagnostic could point wherever we want, starting at the point at which you try to pass it between contexts, then to the type, then to the properties preventing the conformance. It's not really any different than trying to decode a type that has no Decodable conformance.

1 Like

I think it makes a lot of sense that a “marker” protocol can’t make new APIs appear on types, even via extensions. (Users could still, of course, create a protocol refining a marker protocol and have those types adopt that conformance.)

If this is agreed, then it simplifies our reasoning greatly regarding the possible risks/benefits of implicit conformance to Sendable:

What’s the possible harm of implicit conformance where the author hasn’t thought about it? If the rules are sound surrounding which value types can conform via the “checked conformance” route, the only drawback I can see is that future changes to the type could accidentally take away the conformance. In that case, an end user could always add it back with an “unchecked” conformance. This seems strictly better than the alternative of not conforming at all.


Finally chiming in here, trying to earn a bit of my (IMO entirely undeserved, but you all are very kind) authorship credit:

I like this form of the proposal. The high-level mental model is easy enough to grasp heuristically, and the fiddly details — while potentially surprising in context — do all follow naturally from that high-level model.

Speaking to the specific questions in this follow-up review:

  • Sendable is a better name than Concurrent. The latter might imply that multiple concurrency domains can simultaneously use a shared value of the type; the former makes it clear that it is transferring, not sharing, that is safe.

    I do worry a bit that Sendable is an over-broad name. Sending where, across what boundary? Between processes? Over the network?

    A yet-clearer name would be ActorSendable, though that wrongly limits the meanings to actors instead of all forms of concurrency. An even-yet-clearer-but-unacceptably-ugly name would be CrossConcurrencyDomainSendable (yikes). This rabbit hold seems like a bad one; I am willing to accept that, like Codable and @escaping, a potentially more general word takes on a very specific meaning with no further qualification because of how common that one specific meaning is. Given how pervasive the term would be, I’m sure a web search for “swift sendable” would turn up answers for confused new users. Sendable thus strikes me as acceptable.

    I’ll float one possible alternative: AsyncSendable. Here it is in context:

    struct Person : AsyncSendable {
      var name: String
      var age: Int
    struct UnsafeTransfer<Wrapper> : @unchecked AsyncSendable {
    actor MyContactList {
      func filteredElements(_ fn: @asyncSendable (ContactElement) -> Bool) async -> [ContactElement] { … }


    • It’s clear that the name refers to concurrency, not other kinds of sending.
    • It ties to the async keyword with which this proposal interacts.
    • It perhaps improves searchability.
    • It’s short.
    • It still loosely respects Rust’s term of art.

    Marginally better? Perhaps. As I wrote above, Sendable is acceptable; this is not something I have Strong Feelings™ about.

  • Being able to mark individual properties @unchecked instead of the entire type is a very compelling idea, and we should consider it sooner rather than later. Having one nuisancy property spoil the safety checking for an entire type is a recipe for future bugs: a large type gets marked @unchecked Sendable because of one dark corner, then another developer comes along later and adds features to another part of the type, not spotting the @unchecked at the top of the file and expecting Swift’s usual level of static safety.

  • The annotation burden of adding Sendable to many types seems low to me. The rationale regarding mindfulness about public API contracts is entirely compelling. The migration path for Error seems sensible. I approve of the proposal’s approach to “rip the band-aid off” in one go rather than introducing an unsafe actor regime first, then trying to migrate to safety later.

A few of other things that still stand out to me, which do not necessarily need to hold up this proposal, but deserve future consideration:

  • Being unable to say if val is Sendable or val as? Sendable is a generality gap that is going to force a few scattered pieces of framework code into nasty corners. It deserves attention. (Thumbnail sketch: We have some heterogenous collection of assorted values, a cache, maybe, or lookup dynamically constructed from configuration, who knows. We need to share values in it across concurrency domains. We have some boxing mechanism that allows for safe sharing of non-async-sendable types, but it’s costly, and we want to optimize it away with a runtime type check when possible. Oops.)
  • What is @_marker, really? The proposal sketches out the loose meaning clearly enough, but it’s not quite clear why it needs to exist at all, or what it really means in practice. Is the import nothing more than the fact that Sendable is a compile-time-only type, and the compiler doesn’t emit any runtime support for it? Is it thus purely optimization, or is there a reason why a Sendable type can’t exist at runtime? Are there other types that have similar problems, and should @_marker be a public feature?
  • The spelling of @unchecked Sendable reads clearly enough, which is the main concern for this proposal, but it raises questions about annotations on protocol conformances. Is there some generality here we need to consider — in terms of user mental model, in terms of language capability? Or is this entirely a syntactic one-off, and developers should treat @unchecked Sendable as a single non-decomposable thought, much like @private(set)? What precedent does this create, if any? (Are there any per-conformance annotations in the language already?)

Yes, thank you, this was an oversight; it's covered in the announcement, but not in my brief summary of the announcement here. I've added a bullet briefly describing this change.

1 Like

Instead of having implicit conformance, when you pass a non-Sendable value to where one is expected (say to an actor), could Xcode offer a fix-it to add it for you?

1 Like
Terms of Service

Privacy Policy

Cookie Policy