<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 13, 2017, at 10:30 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I’m confused I thought we were talking about the naming choices for the argument labels in those functions. I think defining and abiding by consistent meanings for `<span style="font-family: monospace, monospace;" class="">count</span>`, `<span style="font-family: monospace, monospace;" class="">capacity</span>`, and `<span style="font-family: monospace, monospace;" class="">bytes</span>` is a good idea, and it’s part of what this proposal tries to accomplish. Right now half the time we use `count` to refer to “bytes” and half the time we use it to refer to “instances”. The same goes for the word “capacity”. This is all laid out in the document:<br class=""><br class="">“““<br class=""><em class="">Finally, the naming and design of some<span class="Apple-converted-space"> </span><code class="">UnsafeMutableRawPointer</code><span class="Apple-converted-space"> </span>members deserves to be looked at. The usage of<span class="Apple-converted-space"> </span><code class="">capacity</code>,<span class="Apple-converted-space"> </span><code class="">bytes</code>, and<span class="Apple-converted-space"> </span><code class="">count</code><span class="Apple-converted-space"> </span>as argument labels is wildly inconsistent and confusing. In<span class="Apple-converted-space"> </span><code class="">copyBytes(from:count:)</code>,<span class="Apple-converted-space"> </span><code class="">count</code><span class="Apple-converted-space"> </span>refers to the number of bytes, while in<span class="Apple-converted-space"> </span><code class="">initializeMemory<T>(as:at:count:to:)</code><span class="Apple-converted-space"> </span>and<span class="Apple-converted-space"> </span><code class="">initializeMemory<T>(as:from:count:)</code>,<span class="Apple-converted-space"> </span><code class="">count</code><span class="Apple-converted-space"> </span>refers to the number of strides. Meanwhile<span class="Apple-converted-space"> </span><code class="">bindMemory<T>(to:capacity:)</code><span class="Apple-converted-space"> </span>uses<span class="Apple-converted-space"> </span><code class="">capacity</code><span class="Apple-converted-space"> </span>to refer to this quantity. The always-problematic<span class="Apple-converted-space"> </span><code class="">deallocate(bytes:alignedTo)</code><span class="Apple-converted-space"> </span>method and<span class="Apple-converted-space"> </span><code class="">allocate(bytes:alignedTo:)</code><span class="Apple-converted-space"> </span>type methods use<span class="Apple-converted-space"> </span><code class="">bytes</code><span class="Apple-converted-space"> </span>to refer to byte-quantities. Adding to the confusion,<span class="Apple-converted-space"> </span><code class="">UnsafeMutableRawBufferPointer</code><span class="Apple-converted-space"> </span>offers an<span class="Apple-converted-space"> </span><code class="">allocate(count:)</code><span class="Apple-converted-space"> </span>type method (the same signature method we’re trying to add to<span class="Apple-converted-space"> </span><code class="">UnsafeMutableBufferPointer</code>), except the<span class="Apple-converted-space"> </span><code class="">count</code><span class="Apple-converted-space"> </span>in this method refers to bytes. This kind of API naming begets stride bugs and makes Swift needlessly difficult to learn.</em><br class="">”””<br class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The only convenience methods this proposal is trying to add is the functionality on the buffer pointer types. There seems to be broad support for adding this functionality as no one has really opposed that part of the proposal yet. Any other new methods like `<span style="font-family: monospace, monospace;" class="">UnsafeMutablePointer.assign(to:)</span>` are there for API consistency.<br class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">This proposal also calls for getting rid of one of those “redundant initializers” :)</div></div></blockquote></div><br class=""><div class="">Since we’re not bike-shedding the specifics yet, I’ll just give you some background.</div><div class=""><br class=""></div><div class="">We would ultimately like APIs that allocate and initialize in one go. It’s important that the current lower-level (dangerous) APIs make a clear distinction between initialized and uninitialized memory to avoid confusing them with future (safer) APIs. `capacity` always refers to memory that may be uninitialized. I think that’s very clear and helpful.</div><div class=""><br class=""></div><div class="">In the context of pointers `count` should always be in strides. For raw pointers, that happens to be the same as as `bytes`.</div><div class=""><br class=""></div><div class="">I initially proposed copy(bytes:from:), but someone thought that `bytes` in this particular context did not properly convey the "count of bytes" as opposed to the source of the bytes. You’re right, that’s inconsistent with allocate/deallocate(bytes:), because allocateBytes(count:) would be silly. Just be aware that the inconsistency is a result of over-thinking and excessive bike shedding to the detriment of something that looks nice and is easy to remember.</div><div class=""><br class=""></div><div class="">I should also point out that the inconsistencies in functionality across pointer types, in terms of collection support and other convenience, is also known but was deliberately stripped from proposals as “additive”.</div><div class=""><br class=""></div><div class="">-Andy</div></body></html>