[swift-evolution] Pitch: Improved Swift pointers
kelvin13ma at gmail.com
Tue Jul 18 13:36:44 CDT 2017
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.
> 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:
> 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
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
255, count: 100)` doesn’t read quite as naturally in English as
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:
> > initializeMemory<Element>(as:from:count:) moveInitializeMemory<Element>(
> > and bindMemory<Element>(to:count:) to UnsafeMutableRawBufferPointer
> > 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
> > adding an initializer UnsafeMutableBufferPointer<
> Element>.init(allocatingCount:) instead > of a type method to
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution