Proposal returned for revision
The core team is highly supportive of solving the problem posed by this proposal, but has decided to return this proposal for revision, pending more experience and examples to help guide the final design. Discussion during review focused on the correct invariants to expect if an error is raised from the closure. Two alternatives were primarily discussed:
- The functions could assume that the buffer has only the first
initializedCountelements initialized, regardless of exit on error or normal return. This provides consistent behavior in the throwing and non-throwing cases, and is convenient for algorithms that initialize the buffer in order so can keep the initializedCount updated as the algorithm progresses. This is what the proposal as written suggests. - The functions could assume that the buffer is completely uninitialized when the closure throws. This is in some ways the safest option, since the worst mistake that could happen is that leaks occur due to values in the buffer not getting cleaned up rather than arbitrary undefined behavior.
It's not clear which behavior is better in practice without more experience working with the API. Programmed against either design, an algorithm that can fail which initializes the buffer out of order has to do the same bookkeeping to determine what values to clean up when an error is thrown. It also isn't clear how useful this API is for the in-order-initialization case, since in principle such algorithms should be expressible using reserveCapacity and append with the same performance. The error handling behavior is also more complex to consider for withUnsafeMutableBufferPointerToStorage; as a mutating method, it modifies an existing value rather than a new value under construction, and it isn't clear how much we ought to try to maintain the state on the existing value. The core team feels that usage experience is necessary to inform the design here as well.
The core team would like to see discussion continue to converge on the correct design for this feature. Particularly, we would like to see concrete examples of use cases for both of these APIs to help inform the decision about throwing behavior.
Thanks to everyone who contributed to the review!