[Accepted] SE-0474: Yielding Accessors

Evolution Announcements
1

Hi all --

The review of SE-0474 ran from April 8 to April 22nd.

Feedback was generally light, probably because this feature has already been extensively discussed in multiple pitches and a draft vision document over a period of a few years, and has existed in underscored form in the standard library even longer than that.

There was some concern raised about a proliferation of different accessors, but the LSG is convinced that we genuinely do need these forms to make Swift as efficient and usable as it should be. The prospective vision document lays out the bigger picture for accessors convincingly, and these are a first step that only codifies an existing underscored feature, so we feel that we are on well-trod API ground.

Accordingly, the LSG has decided to accept this proposal.

I will note that as a practical matter, there are some implementation kinks that have to be worked out before this change is merged. In particular, as implemented, this would be source-breaking. The authors have assured me that they will be able to narrow the impact of the source break to an acceptable impact (or eliminate it entirely), but this change will not land until that happens, likely after the 6.2 release.

Thank you all for your participation in Swift Evolution.
– Steve Canon

19 Likes
2

Was there ever a discussion about how nonmutating yielding mutate is potentially confusing?

3

Could one of the authors resolve this minor question please? SE-0474: Yielding Accessors - #9 by woolsweater

4

This is covered (somewhat indirectly) in the prospective vision document. These can be protocol requirements, but if you read between the lines, it should be somewhat less common to use the yielding accessors in that way. More frequently they will be used as an implementation detail to implement a “normal” get/set requirement.

The non-yielding borrow and mutate accessors described in that document are expected to be the more common case for protocols that have to interact with non-copyable types.

5

All right, thanks.