# SE-0310: Effectful Read-only Properties

**URL:** <https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401>\
**Category:** Proposal Reviews\
**Created:** [April 13, 2021, 10:18pm UTC](https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401 "2021-04-13T22:18:32Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![kavon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kavon/32/9774_2.png) [@kavon](https://forums.swift.org/u/kavon)\
**Post date:** [April 14, 2021, 4:59pm UTC](https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401/16 "2021-04-14T16:59:59Z")

</div>

> [@OneSadCookie](#):
>
> I don't feel that the proposal sufficiently justifies why a property that is asynchronous or throws would not be better expressed as a method. As it points out, people expect properties to be cheap, O(1), not worth manually extracting common subexpressions. Throwing and async properties inherently break all those assumptions.

Effectful properties and subscripts do not inherently break this time-complexity assumption. Effects specifiers on a `get` accessor only indicate what might happen during the access that the use-sites must take into account:

- For `throws`, the user must be prepared for an `Error` value to be returned instead of the expected value.
- For `async`, the user must be within an asynchronous context, because the accessor may require a suspension of the current task to produce a result, for example, to gain exclusive access to an `actor`'s state. In fact, `async` properties _prevent_ users from accidentally blocking on a computed property, because `async` requires that the users of the property take its possible suspension into account (this is explained in the `AVAsynchronousKeyValueLoading` example).

It's still up to the programmer to stay within the guidelines that users expect, an amortized O(1) time for the accessor, regardless of the effects the accessor may exhibit. This is achieved in the usual way for any non-trivial computed property or subscript, by returning a cached answer when possible.

To expand a bit on one of the examples in the proposal: for [AVAsynchronousKeyValueLoading](https://developer.apple.com/documentation/avfoundation/avasynchronouskeyvalueloading), which has [AVAsset](https://developer.apple.com/documentation/avfoundation/avasset) as one of its conformers. One of AVAsset's potentially blocking computed properties is `var duration: CMTime`. If the asset isn't downloaded already, it will block, so it's still O(1) amortized. Should that property instead be the method `func getDuration() -> CMTime` instead? I think that's a stylistic decision that is up the API author.

Of course, if it's not possible to cache the result and a non-trivial computation is _always_ required, then a computed property or subscript is indeed not a good choice. **Edit** : well, _possibly_ not a good choice. For example, `subscript` on various data structures is not O(1) and that is a reasonable expectation. Chris also pointed out `var count` as well.

---

_[View the full topic](https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401)._