# \[Accepted\] SE-0340: Unavailable From Async Attribute

**URL:** <https://forums.swift.org/t/accepted-se-0340-unavailable-from-async-attribute/55356>\
**Category:** Announcements\
**Created:** [February 15, 2022, 11:02pm UTC](https://forums.swift.org/t/accepted-se-0340-unavailable-from-async-attribute/55356 "2022-02-15T23:02:33Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [February 17, 2022, 9:45pm UTC](https://forums.swift.org/t/accepted-se-0340-unavailable-from-async-attribute/55356/4 "2022-02-17T21:45:18Z")

</div>

> [@Karl](#):
>
> Sure, I don't think anybody disagrees with the principle. The argument is that just wrapping the unavailable-from-async function in an unannotated function is not the right way to go about it. As written, you could easily expose async code to these APIs by accident - indeed, that will be the default.
> 
> IMO, if you are wrapping an unavailable-from-async function in a way that makes it safe for async code, that should be an explicit thing. It shouldn't be possible to do by accident.

A transitive restriction would definitely be more powerful for asserting correctness, but would also be much more disruptive to the existing ecosystem, and in our judgment, the Core Team didn't think the cost/benefit tradeoff of a transitive restriction made sense for this functionality, especially when there is already a large transition underway for `Sendable` restrictions coming in Swift 6.

> [@Karl](#):
>
> This still feels like a case of using something that already exists, even if it isn't a good fit, just to save implementation effort. As I mentioned during the review, we are planning for whole categories of attributes which would like similar availability constraints, and this solution does not scale.
> 
> I would have appreciated some feedback from the proposal author on these points during the review. It was a quiet review; there were only a handful of comment to respond to.

I'm sorry you didn't get more direct engagement during the review. The Core Team did discuss this point, though, and we decided to go with the proposed availability-based syntax for the reasons mentioned—particulary because public discussion in the pitch had already steered the originally-proposed design toward availability. It is a reasonable concern whether this is a stretch of the availability constraint, but the availability syntax already has several uses not directly related to OS availability. You are right that there are looming scalability issues for generalizing versioning across all attributes it's interesting for. (My own thoughts on that are that our existing availability scheme is already struggling to scale for clients such as the standard library that rely heavily on ABI stability and versioning, and we should probably consider an alternative approach to attributes in the implementation source code for managing interface versioning after a certain point.)

---

_[View the full topic](https://forums.swift.org/t/accepted-se-0340-unavailable-from-async-attribute/55356)._