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

Excellent refinement.

It seems we just dodge the ambiguity. The result builders, the property wrappers, and the "autogenerated conformance" would be using either Type name or Protocol name, both of which share the namespace :thinking:. Except when someone has X that is both result builder and property wrapper ofc.

Currently all of the custom-attribute types have to opt in to being an attribute in some specific way (e.g. the @propertyWrapper attribute), and that determines how they're interpreted. A single type can't opt in to being an attribute in multiple ways, so there's no technical ambiguity. Maybe we'll have to do that here when we generalize it beyond Sendable, so that protocols used this way can't be used directly as e.g. result builders or protocol wrappers. Although I really don't know why you would use a protocol for either of those in the first place, and indeed you would need some significant enhancements to protocols to even try.

I don't think it's a real problem that nothing about what interpretation a specific custom attribute has is obvious from the syntax alone — or at least, to the extent it's a real problem, it applies to attributes/modifiers/keywords in general, not just to custom attributes. Attribute names should be well-chosen so that a reader's first guess is close enough to not be wildly misleading.


This is what we're saying, that there's a plausible path of future generalization that would let you do this to arbitrary protocols (or at least a growing set of them), and so we should use a spelling that makes this fit with that rather than giving it a spelling that will stand out as a special case.


Oh, sorry, I assumed that this comment

meant that such path could lead to undesirable complexity and should be avoided, except for marker protocols. No further questions then!

+1 I like it.

I am assuming @autoclosure @Sendable is supported. I don’t think I saw it mentioned.

@unchecked is not sitting right with me. It’s a brand new feature in the language.

Can it be underscored until it has a proper review? @_unchecked will allow folks to know this in an internal feature.

@unchecked in being added unchecked into the language. (Sorry)

1 Like

Sorry, but could you clarify what you feel was improper about the current review? Because this use of @unchecked was explicitly part of this review.

If you have more feedback about it, well, we’re not sticklers about review periods, and nothing’s written in stone; you can just say what you mean to say, and we’ll take it into consideration.

The position where @unchecked applies to a protocol conformances is brand new outside of the work of SFTF.

I like how @_marker was introduced:

We think this is a generally useful feature, but believe it should be a compiler-internal feature at this point. As such, we explain it and use this concept with the “ @_marker ” attribute syntax below.

We are adding 3 different types of attributes to Swift in this proposal.

  • Marker (cool, underscored, internal)
  • Protocol conformance attribute (cool, just a naming convention change, precedented by @escaping
  • uncheck conformances ( I think this one is too different and deserves it’s own mini review outside of this proposal so my suggestion is for the escape hatch to be provided but as @_unchecked )

typealias UncheckedSendable = @_unchecked Sendable

Yes, and it was reviewed in this proposal, so I'm really not sure why you keep saying it's unreviewed. What additional process would you like to have seen besides the formal evolution review that occurred?

Thanks for asking. This @unchecked feature is ancillary syntactic sugar to what it’s being proposed. Given Swift’s high bar for syntactic sugar I was somewhat surprised this (in my view) single use case compiler feature is now part of the public user API. It makes Swift unnecessary a little more complex IMO which is not sustainable on the long run.

Well, no, it's not sugar, as there's no other way to get that behavior. The proposers, and the core team, believe quite strongly that it's a necessary part of the model, and that this is a reasonable way of spelling it.


Ah, I see. Thank you for the explanation.

Function types conforming to arbitrary protocols is certainly an interesting design space!

And “metaprogram a conformance to an arbitrary protocol”…be still my heart.

1 Like

This proposal is straightforward and powerful. I appreciate the nuanced thinking, acknowledging the realities of day-to-day development without compromising our aspirations for an ideal world.

I like the @Sendable spelling idea, looks fine, and feels like there definitely could be more such use-cases eventually.

My only concern was if we're "using up" this mechanism and it'd prevent us in the future from doing @Traced func hello() {} but as I wrote up the details of my concern I realized I think we're good.

A user-defined Traced/Sendable would have to conform to some protocol to express that it is such "wrapper", and we'd simply have another such protocol type to make a type a func vs. function literal wrapper I suppose? That's still far out of course, but wanted to make sure the potential future work with this fits in well with what @Sendable mechanisms we're imagining. I realize this is all future work of course though :slight_smile:

As I understand it, what you want from @Traced is to modify a function definition to implicitly insert tracing in its prologue/epilogue. That sounds like a custom attribute, but one that's quite mechanically different from this. Unless you think @Traced needs to change the function type?


Correct, it would not be changing the type in any way except injecting some code before/after the actual functions body.

So mechanically different but just wanted to check in if that’ll still be viable as a what those future user defined ‘@‘ attributes could be or if this Sendable is setting some more precedent that such things actually change type (I guess function wrappers also change the type and hide the wrapped real thing and type inside them).

To be clear, this is not the first kind of custom attribute, so yeah, this wouldn't be setting any precedent that all custom attributes on functions work this way.

1 Like

Cool yeah, just wanted to double check on this in case some macro like things were pondered wrt. this discussion in the core meeting :-) yeah there’s plenty other attributes around already after all.


Terms of Service

Privacy Policy

Cookie Policy