The third review of SE-0258 has concluded. There was a lot more great discussion in this review, and while there were some questions and reservations, overall the community expressed strong support for accepting the proposal. The Core Team agrees and has decided to accept SE-0258 with only one minor change: we would like to accept the community's suggestion that the initialValue: argument label on wrapper initializers be renamed to wrappedValue: to match the property name. The Core Team feels that this is a minor enough change to make without a further round of review.
This has been a long and fruitful evolution review, encompassing three separate formal review periods and quite a few rounds of pitching and redevelopment. As the review manager, I appreciate how the community has handled itself throughout this process. It is a goal of evolution to not merely pass judgment on proposals but to ensure that they are as good as they can be, and I think SE-0258 has been a model for that in many ways. We now have a far better language design than we started with, and for that the credit goes both to the adaptability and patience of the authors and to the persistence and energy of the community. By thinking hard about the feel of the feature, by pushing on its expressive potential, and by actually trying it out and relaying back its strengths and weaknesses, the community has shaped and improved it immeasurably.
I say this in every review, and I mean it honestly: thank you for helping to make Swift a better language.
I do not know if this is the right place to ask the question, please redirect me as needed if this is the wrong place.
My question is how the update to the documentation for evolutions is made available, and how the update of the existing documentation is happening?
Like many others I have had a hard time following the changes in the Combine API over the last year.
API documentation mostly provide a simplified documentation on how to use the API, but I was thinking a little differently.
In the case of property wrappers there has been so many changes the past year that a changelog with old and new modified names would be very helpful.
Maybe it already exists?
Regards
Lars
Swift newbie
There were almost no changes to PWs after they got accepted. The only changes that happened were after WWDC19. The current design is fully described in the Property Wrapper proposal on the swift-evolution repository.
If you want to stay up to date, I recommend to follow the evolution repo or the linked webpage.
Thank you for the answer and the link.
I find the documentation quite overwhelming, and indeed part discussion around the creation of the proposal and documentation.
Please, I am not being critical, but it is an architectural document, and I was more looking for a comprehensive user (developper) documentation.
People like me do not have the capacity, nor the wish to be a language architect.
My objective is to have pleasure developing with Swift, and maybe in some years this kind of lecture will be for me, but for the time being I need something simpler.
After re-reading the accepted proposal, I still wasn't clear on the answer to this question: Is there a path forward to allow for the ability to access self of the enclosing type (not the wrapper type) within the initial value of a stored property (such as a closure) when used in conjunction with a property wrapper?
The accepted proposal mentions how lazy could not be completely implemented as a property wrapper because of this point, but also disallows the use of lazy with property wrappers, which seems to leave functionality to be desired. Is there a future direction that allows for this? I can imagine some really interesting use cases if this were possible.
As a note: While I may have overlooked it, I couldn't find a specific reason stating why lazy is disallowed with property wrappers (other that the fact that there may be a future attempt to replace most of lazy's utility with a @Lazy property wrapper).
I appreciate all help given.