[Accepted] SE-0475: Transactional Observation of Values

Evolution Announcements
1

Hello Swift community,

The review of SE-0475: Transactional Observation of Values ran from April 10th through May 13th, 2025. The Language Steering Group has decided to accept the proposal. This acceptance is inclusive of changes made to the proposal by the author in response to the review, namely that:

  • The name of the introduced type in this proposal will be Observations.
  • All iterations of a specific Observations sequence will produce an initial value, not just the first iteration.

There was a good amount of discussion on this proposal and a lot of subtle edge cases to cover, so much of the review was spent probing the proposed semantics. The Language Steering Group is comfortable with the behavior of this sequence as explained in the proposal and elaborated on in review and think it fills an important ergonomic gap in the current withObservationTracking API surface.

Some reviewers were concerned about the inherently async nature of this API and called out problems faced by using this sort of API compared to a fully-synchronous API. The Language Steering Group is sympathetic to these concerns, and agrees that the shape of API proposed here may not be appropriate for every use case. Accepting the Observations type does not indicate an unwillingness to consider other shapes of observation in Swift and the Language Steering Group felt that, especially with the name change, there was sufficient space being left to consider an alternate API in the future, if such a proposal ever arose. Moreover, the Language Steering Group felt that such an alternative would not obviate the need for Observations as-proposed.

As always, thank you to everyone who participated for helping to make Swift a better language.

Freddy Kellison-Linn
Review Manager

7 Likes
2

thanks Freddy. i'm not sure what the right venue for this form of feedback is, so hopefully posting here is alright (if not, perhaps someone with appropriate permissions could relocate it).

during the pitch & review for this feature, there were a number of issues raised regarding specifics of the associated implementation PR, the discussion of which received some pushback as 'detracting' from the intended focus on the design.

as someone who believes implementations matter quite a bit (after all, they are the only thing that brings a design 'to life', so to speak), my experience during this pitch & review has left me somewhat confused as to how implementation feedback is supposed to fit into this stage of the evolution process. in particular, these are a few questions i've been wondering about:

  1. does the LSG consider the proposed implementation and any associated PR discussion in its determinations?
  2. are proposal authors expected to respond to implementation feedback during the review?
  3. are review managers typically familiar with a feature's implementation and any PR feedback, or is that outside of the role's purview?

i was under the impression that the review period would be a good time to have 'extra eyes' on an implementation to try and catch issues before they ship. however, i noticed that the implementation PR was merged shortly after this acceptance announcement was posted, but a number of outstanding comments & questions were left unaddressed (disclaimer – most are mine). additionally, AFAICT there were no tests provided for the new functionality, despite this being a nominal requirement in the contributing guidelines[1].

having spent quite a bit of time and energy understanding the implementation and surfacing possible issues, the fact that that work appeared to both not be welcome in the review thread, and PR feedback was left seemingly ignored before the implementation was merged is both discouraging and a bit baffling.

anyway, the feature does seem interesting and potentially quite useful, even if i think it still has some problematic edge cases.

  1. though i did offer one during the review to highlight an implementation issue ↩︎

4 Likes
3

To answer generally, the relationship between the implementation and the review process is that we require at least a prototype implementation be provided prior to scheduling a review. This prototype need not be in any sort of mergable state, and we do not make an effort to validate that it is entirely bug-free. Rather, the purpose of this requirement is to ensure that there are no major holes in the proposed semantics that would make them fundamentally unimplementable, and also to ensure that there is someone involved with the proposal who could feasibly take on the project of getting the implementation landed on main.

Prior to this requirement, it happened a few times that proposals came to the mailing lists, were reviewed and approved, and then either nobody took on the implementation project (leaving the proposal to languish), or else it was discovered during implementation that there was some serious issue with the proposal which required another round of review to settle.

To answer your specific questions:

  1. does the LSG consider the proposed implementation and any associated PR discussion in its determinations?

No, specific implementation details are generally considered out of scope for proposal review and the LSG does not cover PR comments as part of our decision. The extent to which implementation concerns factor into the review process is basically limited to a feasibility analysis. More recently we've also made an effort to ensure that the implementation also be made available in a toolchain/package so that reviewers can evaluate the feature by using it themselves, and I'd say this admits one additional exception to 'implementation feedback is out of scope for review threads', which I mentioned during review:

  1. are proposal authors expected to respond to implementation feedback during the review?

No, it is not expected that implementation feedback be addressed during review. The review process and implementation process are only loosely coupled in the specific following ways:

  1. A prototype implementation must be provided in order to bring a proposal to review.
  2. Accepted proposals must have their implementations landed within one year of acceptance or else they are subject to re-review.
  3. Public changes to the language surface must go through LSG review before they are released.

Beyond that, implementation proceeds largely independently of the review process. Whether PRs are merged is governed by the maintainers of the compiler repo and the LSG's formal role ends once we have approved or rejected a proposal. It is not uncommon for implementations to undergo substantial changes after being accepted, or to require several follow-up PRs to sufficiently harden the implementation.

  1. are review managers typically familiar with a feature's implementation and any PR feedback, or is that outside of the role's purview?

The RM is responsible for ensuring that proposal authors have provided an implementation of sufficient quality to validate a substantial portion of the proposed semantics. However, as mentioned above, monitoring implementation feedback is not part of the review process.

I don't want to come across as though I'm being dismissive about your implementation concerns—I think you raise good questions about how community members can best surface this sort of feedback, but I don't believe proposal reviews are the right venue. This could be a good discussion to raise in Contributor Experience!

5 Likes
4

thank you for the prompt, thorough, and edifying response – much appreciated!

1 Like