<div dir="ltr">I agree it’s probably a bad idea to add the default arg to those two functions. However, the default argument in initialize(repeating:count:) is there for backwards compatibility since it already had it before and there’s like a hundred places in the stdlib that use this default value.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 19, 2017 at 6:02 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span class=""><div>On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-6780494060929294959Apple-interchange-newline"></span><div><div class="h5"><div><div dir="ltr">Implementation is here: <a href="https://github.com/apple/swift/pull/11464" target="_blank">https://github.com/apple/<wbr>swift/pull/11464</a><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I’ve revised the proposal based on what I learned from trying to implement these changes. I think it’s worth tacking the existing methods that take <span style="font-family:monospace,monospace">Sequence</span>s at the same time as this actually makes the design a bit simpler.<br><div><<a href="https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c" target="_blank">https://gist.github.com/kelvi<wbr>n13/5edaf43dcd3d6d9ed24f303fc9<wbr>41214c</a>><br><i><br></i><div style="margin-left:40px"><i>The <a href="https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907" target="_blank">previous version</a> of this document ignored the generic initialization methods on <code>UnsafeMutableBufferPointer</code> and <code>UnsafeMutableRawBufferPointer</code>,
leaving them to be overhauled at a later date, in a separate proposal.
Instead, this version of the proposal leverages those existing methods
to inform a more compact API design which has less surface area, and is
more future-proof since it obviates the need to design and add another
(redundant) set of protocol-oriented pointer APIs later.</i></div></div></div><div class="m_-6780494060929294959gmail-HOEnZb"><div class="m_-6780494060929294959gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you!<br><<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md" target="_blank">https://github.com/apple/swif<wbr>t-evolution/blob/master/propos<wbr>als/0184-improved-pointers.md</a>><br></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></div></div></blockquote></div><div><br></div>Thanks for continuing to improve this proposal. It’s in great shape now.<div><br></div><div>Upon rereading it today I have to say I strongly object to the `count = 1` default in the following two cases:<div><div><br></div><div>+ UnsafeMutablePointer.<wbr>withMemoryRebound(to: count: Int = 1)</div><div>+ UnsafeMutableRawPointer.<wbr>bindMemory<T>(to:T.Type, count:Int = 1)</div><div> -> UnsafeMutablePointer<T></div><div><br></div><div>To aid understanding, it needs to be clear at the call-site that binding memory only applies to the specified number of elements. It's a common mistake for users to think they can obtain a pointer to a different type, then use that pointer as a base to access other elements. These APIs are dangerous expert interfaces. We certainly don't want to make their usage more concise at the expense of clarity.</div><div><br></div><div>In general, I think there's very little value in the `count=1` default, and it creates potential confusion on the caller side between the `BufferPointer` API and the `Pointer` API. For example:</div><div><br></div><div>+ initialize(repeating:Pointee, count:Int = 1)</div><div><br></div><div>Seeing `p.initialize(repeating: x)`, the user may think `p` refers to the buffer instead of a pointer into the buffer and misunderstand the behavior.</div><div><br></div><div>+ UnsafeMutablePointer.<wbr>deinitialize(count: Int = 1)</div><div><br></div><div>Again, `p.deinitialize()` looks to me like it might be deinitializing an entire buffer.</div><div><br></div><div>If the `count` label is always explicit, then there's a clear distinction between the low-level `pointer` APIs and the `buffer` APIs.</div><div><br></div><div>The pointer-to-single-element case never seemed interesting enough to me to worry about making convenient. If I'm wrong about that, is there some real-world code you can point to where the count=1 default significantly improves clarity?</div></div><div><br></div></div><div>-Andy</div></div></blockquote></div><br></div>