[swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift]

On Tue, Jul 18, 2017 at 2:18 PM, Andrew Trick <atrick at apple.com> wrote:

>
> > rename count in UnsafeMutableRawBufferPointer.allocate(count:) to bytes
> and add an
> > alignedTo parameter to make it UnsafeMutableRawBufferPointer.
> allocate(bytes:alignedTo:)
>
> Memory allocation is an issue unto itself. I generally prefer your
> proposed API. However...
>
> 1. Larger-than-pointer alignments aren't currently respected.
>
> 2. Users virtually never want to specify the alignment explicitly. They
>    just want platform alignment. Unfortunately, there's no reasonable
>    "maximal" alignment to use as a default. I think pointer-alignment
>    is an excellent default guarantee.
>
> 3. The current allocation builtins seem to presume that
>    allocation/deallocation can be made more efficient if the user code
>    specifies alignment at deallocation. I don't think
>    UnsafeRawBufferPointer should expose that to the user, so I agree
>    with your proposal. In fact, I think aligned `free` should be
>    handled within the Swift runtime.
>
> Resolving these issues requires changes to the Swift runtime API and
> implementation. This might be a good time to revisit that design, but
> it might slow down the rest of the proposal.
>
>
I don’t know much about the Swift runtime, but for now at least, it might
be a good idea to emit a runtime error if an alignment larger than a
pointer is specified, if only when built in debug mode.


> > fix the ordering of the arguments in initializeMemory<Element>(as:
> at:count:to:)
>
> I think this ordering was an attempt to avoid confusion with binding
> memory where `to` refers to a type. However, it should be consistent
> with `UnsafePointer.initialize`, so we need to pick one of those to
> change.
>

This would be a non-issue had we just been consistent with the rest of the
stdlib and named this argument `repeating:` instead of `to:`. But
`ptr.initialize(repeating:
255, count: 100)` doesn’t read quite as naturally in English as
`ptr.initialize(to:
255, count: 100)` which is why I left this idea out of the proposal. Now
that you mention the problem with `initializeMemory<Element>(as:
at:count:to:)`, it might be a good idea to add this rename back into it.


>
> > add the sized memorystate functions withMemoryRebound<Element,
> Result>(to:count:_:) to
> > UnsafeMutableBufferPointer, and initializeMemory<Element>(as:
> at:to:count:),
> > initializeMemory<Element>(as:from:count:) moveInitializeMemory<Element>(
> as:from:count:),
> > and bindMemory<Element>(to:count:) to UnsafeMutableRawBufferPointer
>
> Yay!
>
> > add mutable overloads to non-vacating memorystate method arguments
>
> I'm not sure removing the need for implicit casts is a goal. I did
> that with the pointer `init` methods, but now I think that should be
> cleaned up to reduce API surface. I think smaller API surface wins in
> these cases. Is there a usability issue you're solving?
>

Yes, I can imagine initializing a mutable pointer to some values, and then
wanting to use that pointer as a source to initialize more buffers. Having
to convert a mutable pointer to an immutable pointer is annoying because a
function that takes an immutable pointer obviously shouldn’t care if the
pointer could be mutated anyway. It’s like having to rebind a `var`
variable to a `let` constant before passing it as any non-inout argument to
a function, since function parameters are immutable. At any rate, this only
applies to two out of the seven memorystate operations, so comparably, it’s
not a big API expansion at all.


>
> > add a init(mutating:) initializer to UnsafeMutableBufferPointer
>
> Yes, finally.
>
> > remove initialize<C>(from:) from UnsafeMutablePointer
>
> Yep.
>
> > adding an initializer UnsafeMutableBufferPointer<
> Element>.init(allocatingCount:) instead > of a type method to
> UnsafeMutableBufferPointer
>
> For the record, I strongly prefer a type method for allocation for the
> reason you mention, it has important side effects beyond simply
> initializingn the pointer.
>
>
> -Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170718/09db9908/attachment.html>