# \[Pitch\] Transactional observation of values

**URL:** <https://forums.swift.org/t/pitch-transactional-observation-of-values/78315>\
**Category:** Pitches\
**Tags:** concurrency, asyncsequence, observation\
**Created:** [March 5, 2025, 9:07pm UTC](https://forums.swift.org/t/pitch-transactional-observation-of-values/78315 "2025-03-05T21:07:01Z")\
**Posts on this page:** 1\
**Showing post:** 59

<div class="post-metadata">

**Author:** ![Nickolas\_Pohilets](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nickolas_pohilets/32/10659_2.png) [@Nickolas\_Pohilets](https://forums.swift.org/u/Nickolas_Pohilets)\
**Post date:** [April 2, 2025, 10:05pm UTC](https://forums.swift.org/t/pitch-transactional-observation-of-values/78315/59 "2025-04-02T22:05:36Z")

</div>

I’m thinking if optional return type is a good idea.

My main concern is that if observed value is of optional type itself, then Element will be inferred by removing a level of optionality. And returning `nil` will terminate iteration, instead of being one of the observed values.

Pretty much in all the use cases I can think of, subscribers store a strong reference to the sender and sender maintains a list of weak references to the subscribers. IMO proposal overestimates importance of observing weak references.

But I guess being able to stop iteration from the sender side still might be useful in some cases. I’m not ready to argue for complete removal of this feature.

With this in mind, I think it would be better to have two initializer overloads:

- one taking closure that returns `Element` and cannot stop iteration early
- another that can, but closure returns a dedicated enum type that cannot be confused with `Optional`.

```swift
// 1
Observed { person.maybeName }

// 2
Observed { [weak person] in
    guard let person else { return .finish }
    return .next(person.maybeName)
}

```

---

_[View the full topic](https://forums.swift.org/t/pitch-transactional-observation-of-values/78315)._