[Pitch] Awaitable Assignment

Evolution Pitches
,
7

my understanding of the history from reading up on some of the background here is roughly:

  1. originally async properties/subscripts were entirely unsupported
  2. SE-310 added support for async read-only property/subscript access
  3. the justification in discussions of SE-310 for not expanding async effects to writable properties/subscripts seemed primarily positioned as a scope-reduction strategy, not a feature that should not ('in the fullness of time') be supported.
  4. it has repeatedly been expressed by the language's designers/developers that supporting an 'easy' way to hop between actors for the purposes of accessing single values may not be desirable as it could make it easier to ignore considering the appropriate level of 'transactionality' of actor-isolated access.

here are some references i found for these statements:

i suspect dodging the full 'effectful setters' issue will make this much more plausible to implement, so that seems like a good idea for enabling incremental change.

as to whether it should be done... personally i find myself somewhat ambivalent about this currently. on the one hand, it's at least a superficial inconsistency that you can currently write these 'awaitable assignment' expressions in some cases but not others that 'look the same'. i'm sympathetic to the position that that could be confusing and is not really well-explained by the current diagnostics. but it's less clear to me that that is sufficient rationale for removing this (seemingly intentional) point of friction entirely vs, say, improving the diagnostic feedback to better motivate the existing behavior.

this is not a perfect analogy, but the thing i keep thinking about here is objective-c's atomic properties. if you want to make a single property access in objc free of 'low level' data races, it is exceedingly easy to do – you just slap an atomic attribute in the @property declaration. however, that approach often just trades one problem (data races) for another (logical race conditions). notably, Swift did not choose to adopt this same 'convenience' as a direct language construct; but if you are so inclined, you can essentially implement such a feature through property wrappers or macros.

i guess a rejoinder to that view in this context is essentially what Jon posed above – it's already so easy to introduce race conditions with the existing concurrency model, we might as well remove the need for this boilerplate and point of potential confusion. at the moment however, i don't find myself particularly compelled by that stance.

i am a bit confused on whether there is generally alignment on the concept of async setters in the language more generally. if that's expected to be implemented at some point, would this current limitation remain in place?

8 Likes