[swift-evolution] SE-184 Improved Pointers

[Andrew Trick]

> On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution <swift-evolution at swift.org> 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!
> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md>>


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.

Yay!

> 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
> UnsafeMutableRawPointer

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
default count.

> avoids the contradictory and inconsistent use of count to represent a byte quantity

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
API.

> UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)

Well, I think it's somewhat ridiculous for users to write this every time they allocate a buffer:

`UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo: MemoryLayout<UInt>.alignment)`

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:),
> initializeMemory<Element>(as:from: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?

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170808/9211b862/attachment.html>