Hello, Swift community.
The review of SE-0532: Optional Non-Copyable Improvements and Generalizations originally ran from May 26th through June 8th. On June 30th, the LSG extended the review until July 6th to get more feedback about the naming of several of the proposed APIs.
Overall, feedback was positive, and both the community and the LSG seem satisfied with the functionality being proposed.
Some members of the community asked about how some of these APIs would interact with possible future language enhancements around enum case accessors. The LSG is not concerned about conflict or redundancy here. It is already the case that there are many ways to decompose Optionals that are technically redundant with pattern matching. The LSG feels that Optional is so important in Swift programming, and pattern-matching on it has such a strong bias towards checking its some case, that it will always benefit disproportionately from small tweaks in these areas.
The proposal originally included methods called borrow() and mutate() that return Ref and MutableRef, respectively. In the extension, LSG suggested making these properties named ref and mutableRef. There was no further feedback on these names, and the LSG remains satisfied with them.
The proposal also originally included a mutating method called insert that takes a (non-optional) Wrapped, overwrites the value of the optional, and returns a MutableRef<Wrapped>. Early community feedback disapproved of this name for the method, and the LSG asked for it to be changed as part of the review extension. The proposal author settled on put, and this name seemed to be acceptable to the community. The LSG agrees that it is important for this operation to be named using an active verb, as the side effect is a critical part of its purpose; we are happy enough with put as a natural complement to take.
Accordingly, SE-0532 is accepted with the modifications suggested in the review extension. The proposal document has been updated appropriately, and you can see the exact changes made here.
I'd like to thank everyone who contributed to this proposal and its review; your feedback is a vital part of making Swift a better language.
John McCall
Review Manager