> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution
> <email@example.com> wrote:
> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is
> ready for community review, and I encourage everyone to look it over and
> provide feedback. Thank you!
Excellent. Thanks for patiently iterating on this. I know it's time consuming.
> This differs from the previous draft of this proposal, in that this
> expansion is more additive and less source-breaking, preserving the
> much of the sized API present on UnsafeMutablePointer.
> For the binary operations assign(from:), moveAssign(from:),
> moveInitialize(from:), and initialize(from:), it is assumed that the
> other buffer pointer contains at least as many elements as self does.
Uh-oh! This should be consistent with
UnsafeRawBufferPointer.copy(from:bytes:) (the raw version of
assign/initialize(from:)). There we assume no data is dropped and
allow an uninitalized buffer tail. What was your rationale for the
opposite choice and how can we reconcile these APIs?
> add a default value of 1 to all size parameters on
> UnsafeMutablePointer and applicable size parameters on
I'm generally ok with this if you have seen the benefit of it in real
code. However, I do not think any `repeating:` methods should have a
> avoids the contradictory and inconsistent use of count to represent a byte
Background: Whether you consider an API consistent depends on how you
prioritize the guidelines. Here you've taken guidelines that I started
to use for new raw pointer APIs and given them higher priority than
other guidelines, in this case having the `count` initializer label match
the name of the public property being initialized. I think your change
is an improvement, but there was nothing accidental about the previous
Well, I think it's somewhat ridiculous for users to write this every time they
allocate a buffer:
`UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo:
If anyone reading the code is unsure about the Swift API's alignment
guarantee, it's trivial to check the API docs.
You could introduce a clearly documented default `alignedTo`
argument. The reason I didn't do that is that the runtime won't
respect it anyway. But I think it would be fair to go ahead with the
API and file a bug against the runtime.
> and initializeMemory<Element>(as:at:repeating:count:),
> moveInitializeMemory<Element>(as:from:count:), and
> bindMemory<Element>(to:count:) to UnsafeMutableRawBufferPointer
I think you should move the raw pointer changes to a separate bullet point.
Presumably the raw buffer capacity must match or exceed count * stride?
swift-evolution mailing list