On Tue, Jul 18, 2017 at 2:18 PM, Andrew Trick <atr...@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
