What is your evaluation of the proposal?
+1. I think this is a valuable addition to the Collection protocol hierarchy. We've been talking about this protocol for years - I'm thrilled to see it finally come up for inclusion.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
- There is a clear performance benefit to knowing that a Collection's elements are stored contiguously, especially if its implementation/iterator are otherwise opaque.
- Since C arrays are pointers, interop with C libraries becomes much easier.
- We have several types in the standard library, corelibs and associated projects which already use this pattern to provide a pointer to their storage. Library authors would like the option to write generic algorithms which care about data rather than some specific semantics implied by a type (e.g. Array vs Data).
Does this proposal fit well with the feel and direction of Swift?
I think so. Although there are a couple of nits:
- If we can add a non-mutating
MutableCollectionconformance to UMBP (as suggested above), that would clearly be preferable to aninoutparameter. - I prefer the name
withUnsafeMutableBufferPointerIfContiguous, because I think it more clearly implies that this is a kind of type narrowing. That is to say, I think it makes it more obvious that rather than implementing the customisation point directly, you should conform toMutableContiguousCollection. The documentation should also mention this.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
C++17 includes contiguous iterators. As in this proposal, they imply random access.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read proposal, participated in pitch discussion as well as several others.