# Why do not actor-isolated properties support 'await' setter?

**URL:** <https://forums.swift.org/t/why-do-not-actor-isolated-properties-support-await-setter/73867>\
**Category:** Using Swift\
**Tags:** concurrency, asyncawait, actors\
**Created:** [August 9, 2024, 4:17pm UTC](https://forums.swift.org/t/why-do-not-actor-isolated-properties-support-await-setter/73867 "2024-08-09T16:17:39Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![vns](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vns/32/37396_2.png) [@vns](https://forums.swift.org/u/vns)\
**Post date:** [August 14, 2024, 8:38pm UTC](https://forums.swift.org/t/why-do-not-actor-isolated-properties-support-await-setter/73867/19 "2024-08-14T20:38:44Z")

</div>

> [@Nathan-Molby](#):
>
> if a variable cannot be safely mutated outside of the actor, it should be marked with a private set, just like you would with any other non-actor.

As unexpected coincidence, I've been going few days ago through old threads on concurrency discussion, and there was a nice way to think about this: actor isolation is orthogonal to access control. So you don't fix isolation with access levels, and you don't fix access levels with isolation. This may seem as contradictory to disallowing async setters on actors, but if you think about it – it makes a lot of sense. So actors don't allow such mutations not because this something you would be able to address with access control, but to enforce state isolation.

> [@Nathan-Molby](#):
>
> Regarding the "transaction" argument, I don't see a convincing reason that my transaction cannot entirely consist of setting a variable. Every time I have tried to use an actor, I have ran into this same problem, and every time have had to create a "setter" function like I'm writing in Java.

Transaction argument, while is important (that's number one post in thread you linked!), isn't the main player here IMO. If we go back to original proposal and [review thread](https://forums.swift.org/t/concurrency-actors-actor-isolation/41613), as well as actors model itself, the _core_ idea of actors is to be only holders and protectors of the state. So making async setters now violate this isolation, making isolation a bit blurry concept in general. Again, actor shouldn't be just used as some asynchronous locks, they are much more than that.

Finally, let's consider example from the proposal:

```swift
extension BankAccount {
  enum BankError: Error {
    case insufficientFunds
  }
  
  func transfer(amount: Double, to other: BankAccount) throws {
    if amount > balance {
      throw BankError.insufficientFunds
    }

    print("Transferring \(amount) from \(accountNumber) to \(other.accountNumber)")

    balance = balance - amount
    other.balance = other.balance + amount // error: actor-isolated property 'balance' can only be referenced on 'self'
  }
}

```

Now, let's imagine we allow `async` setters on actors. How it will look like from usage point? Something like

```swift
await other.balance = await other.balance + amount

```

? That's clearly now what we want.

What if we could eliminate second `await` to get

```swift
await other.balance = other.balance + amount

```

Is it one transaction to actor? Or will it first read balance (1st suspension point), then update it (2nd suspension point)? That's unclear from the code, and source of potential errors.

Actor require a bit of shift into using them, so you don't write Java-like setters at all. While they look in Swift like classes from OOP, they aren't them at all.

---

_[View the full topic](https://forums.swift.org/t/why-do-not-actor-isolated-properties-support-await-setter/73867)._