<div dir="ltr">On Tue, Jul 18, 2017 at 2:18 PM, Andrew Trick <span dir="ltr">&lt;<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>&gt;</span> wrote:<br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div style="overflow-wrap: break-word;">&gt; rename count in UnsafeMutableRawBufferPointer.allocate(count:) to bytes and add an<div>&gt; alignedTo parameter to make it UnsafeMutableRawBufferPointer.<wbr>allocate(bytes:alignedTo:)</div><div><br></div><div>Memory allocation is an issue unto itself. I generally prefer your</div><div>proposed API. However...</div><div><br></div><div>1. Larger-than-pointer alignments aren&#39;t currently respected.</div><div><br></div><div>2. Users virtually never want to specify the alignment explicitly. They</div><div>   just want platform alignment. Unfortunately, there&#39;s no reasonable</div><div>   &quot;maximal&quot; alignment to use as a default. I think pointer-alignment</div><div>   is an excellent default guarantee.</div><div><br></div><div>3. The current allocation builtins seem to presume that</div><div>   allocation/deallocation can be made more efficient if the user code</div><div>   specifies alignment at deallocation. I don&#39;t think</div><div>   UnsafeRawBufferPointer should expose that to the user, so I agree</div><div>   with your proposal. In fact, I think aligned `free` should be</div><div>   handled within the Swift runtime.</div><div><br></div><div>Resolving these issues requires changes to the Swift runtime API and</div><div>implementation. This might be a good time to revisit that design, but</div><div>it might slow down the rest of the proposal.</div><div><br></div></div></blockquote><div><br></div><div>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 <span style="font-family:monospace,monospace">debug</span> mode.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div></div><div>&gt; fix the ordering of the arguments in initializeMemory&lt;Element&gt;(as:<wbr>at:count:to:)</div><div><br></div><div>I think this ordering was an attempt to avoid confusion with binding</div><div>memory where `to` refers to a type. However, it should be consistent</div><div>with `UnsafePointer.initialize`, so we need to pick one of those to</div><div>change.</div></div></blockquote><div><br></div><div>This would be a non-issue had we just been consistent with the rest of the stdlib and named this argument `<span style="font-family:monospace,monospace">repeating:</span>` instead of `<span style="font-family:monospace,monospace">to:</span>`. But `<span style="font-family:monospace,monospace">ptr.initialize(repeating: 255, count: 100)</span>` doesn’t read quite as naturally in English as `<span style="font-family:monospace,monospace">ptr.initialize(to: 255, count: 100)</span>` which is why I left this idea out of the proposal. Now that you mention the problem with `<span style="font-family:monospace,monospace">initializeMemory&lt;Element&gt;(as:</span><wbr><span style="font-family:monospace,monospace">at:count:to:)</span>`, it might be a good idea to add this rename back into it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>&gt; add the sized memorystate functions withMemoryRebound&lt;Element, Result&gt;(to:count:_:) to</div><div>&gt; UnsafeMutableBufferPointer, and initializeMemory&lt;Element&gt;(as:<wbr>at:to:count:),</div><div>&gt; initializeMemory&lt;Element&gt;(as:<wbr>from:count:) moveInitializeMemory&lt;Element&gt;(<wbr>as:from:count:),</div><div>&gt; and bindMemory&lt;Element&gt;(to:count:) to UnsafeMutableRawBufferPointer</div><div><br></div><div>Yay!</div><div><br></div><div>&gt; add mutable overloads to non-vacating memorystate method arguments</div><div><br></div><div>I&#39;m not sure removing the need for implicit casts is a goal. I did</div><div>that with the pointer `init` methods, but now I think that should be</div><div>cleaned up to reduce API surface. I think smaller API surface wins in</div><div>these cases. Is there a usability issue you&#39;re solving?</div></div></blockquote><div><br></div><div>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 `<span style="font-family:monospace,monospace">var</span>` variable to a `<span style="font-family:monospace,monospace">let</span>` constant before passing it as any non-<span style="font-family:monospace,monospace">inout</span> 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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>&gt; add a init(mutating:) initializer to UnsafeMutableBufferPointer</div><div><br></div><div>Yes, finally.</div><div><br></div><div>&gt; remove initialize&lt;C&gt;(from:) from UnsafeMutablePointer</div><div><br></div><div>Yep.</div><div><br></div><div>&gt; adding an initializer UnsafeMutableBufferPointer&lt;<wbr>Element&gt;.init(allocatingCount:<wbr>) instead &gt; of a type method to UnsafeMutableBufferPointer</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>-Andy</div></div></blockquote></div><br></div></div></div>