[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick <atrick at apple.com> wrote:

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

The rationale was simply that it’s not straightforward to “finish”
initializing a partially initialized buffer since we don’t have
UnsafeMutablePointer memory initializers that work on offsets from the base
address, so we might as well assume that anyone using it is initializing
the whole buffer in one go. This isn’t really that strong a rationale and
I’m open to switching it to be consistent with
UnsafeRawBufferPointer.copy(from:bytes:).


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

Actually, i believe initialize(to:count:) is currently the one method that
already *has* a default count. That’s probably because the standard library
calls this method with a count argument of 1 more than any other
memorystate method. I don’t know if this decision was only made for the
sake of the stdlib or if it had an API justification.


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

Default argument of MemoryLayout<Int>.alignment is the way to go but as you
said i don’t know if that is actually allowed/works. An alternative is to
have two allocate methods each, one that takes an alignment argument and
one that doesn’t (and aligns to pointer alignment) but that feels
inelegant. Default arguments would be better.


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

The reason the raw buffer pointers don’t fill in their own size is the
destination type might not line up with the raw buffer size, and then
there’s questions of rounding and whatnot. bindMemory(to:count:) would also
have to perform integer division or some other defined behavior. Though if
people think computing the strided count inside the buffer pointer method
is the right way to go, I’m open to that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170808/abf62518/attachment-0001.html>