<div dir="ltr">On Sat, Sep 2, 2017 at 3:36 PM, Andrew Trick <span dir="ltr">&lt;<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Thanks for the review as always…<div><br><div><blockquote type="cite"><span class=""><div>On Sep 2, 2017, at 12:13 PM, Taylor Swift via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_6416729595521158717Apple-interchange-newline"></span><div><div dir="ltr" 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"><div class="gmail_extra"><br class="m_6416729595521158717Apple-interchange-newline"><br><div class="gmail_quote"><span class="">On Sat, Sep 2, 2017 at 10:03 AM, Xiaodi Wu via swift-evolution<span class="m_6416729595521158717Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-<wbr>evolution@swift.org</a>&gt;</span><span class="m_6416729595521158717Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="m_6416729595521158717gmail-">On Sat, Sep 2, 2017 at 12:27 AM, Douglas Gregor via swift-evolution<span class="m_6416729595521158717Apple-converted-space"> </span><span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-<wbr>evolution@swift.org</a>&gt;</span><span class="m_6416729595521158717Apple-converted-space"> </span>wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class="m_6416729595521158717gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)">Hello Swift community,</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)">The review of SE-0184 &quot;Unsafe[Mutable][Raw][Buffer]P<wbr>ointer: add missing methods, adjust existing labels for clarity, and remove deallocation size&quot; begins now and runs through September 7, 2017. The proposal is available here:</p><blockquote style="box-sizing:border-box;margin:0px 0px 16px;padding:0px 1em;border-left-width:0.25em;border-left-style:solid;border-left-color:rgb(223,226,229);background-color:rgb(255,255,255)"><div style="box-sizing:border-box;margin-top:0px;margin-bottom:0px"><font size="3" color="#6a737d" face="-apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md" target="_blank">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0184-unsafe-pointers-add-mi<wbr>ssing.md</a></font></div></blockquote></div></blockquote></span></div></div></div></blockquote></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>## UnsafeMutableBufferPointer</div><span class=""><div><br></div><div>Please clarify: why are you proposing that the `at:` arguments in `UnsafeMutableBufferPointer` and `UnsafeMutableRawBufferPointer<wbr>` _should not_ receive default values, but the `at:` arguments in `UnsafeMutableRawPointer` _should_ receive a default value of `0`?</div></span></div><div><br></div></div></div></div></blockquote><span class=""><div><br></div><div> The extant API for `<span style="font-family:monospace,monospace">UnsafeMutableRawPointer</span>` already included these default arguments which seem to be widely used in the stdlib,, the proposal tries to avoid these kinds of source breakages wherever possible. We avoid providing the default arguments on buffer pointers because we want the fact that it takes a<span class="m_6416729595521158717Apple-converted-space"> </span><i>start–length</i><span class="m_6416729595521158717Apple-converted-space"> </span>segment pair to be obvious at the call site.<br></div></span></div></div></div></div></blockquote><div><br></div><div>That’s right, the buffer pointer API is just one level above pointers. It primarily offers the safety of tracking its capacity and bounds checking in debug mode. It does not help you safely manage fully initialized buffer slices (we *do* want to provide that convenience later as a higher-level non-pointer type). Instead, it exposes segments within the buffer for initialization, assignment, deinitialization. It needs to be obvious in the client code, at every call site, that the caller is responsible for tracking those segments. Earlier iterations of this proposal attempted to hide this as a convenience, but that led to dangerous scenarios.</div><div><br></div><div>Taking at Kelvin’s example:</div><div><br></div><font face="Menlo">var image = <wbr>UnsafeMutableBufferPointer&lt;<wbr>Pixel&gt;.allocate(capacity : maxPixels)<br><br class="m_6416729595521158717Apple-interchange-newline">var filled:Int = 0<br>for scanline: <wbr>UnsafeMutableBufferPointer&lt;<wbr>Pixel&gt; in scanlines {</font><div><font face="Menlo">    image.moveInitialize(at: filled, from: scanline)</font></div><div><font face="Menlo">    filled += scanline.count</font></div><div><font face="Menlo">}</font></div><div><font face="Menlo">…</font></div><div><font face="Menlo">// We don’t want to allow any defaults here.</font></div><div><font face="Menlo">// It’s important for the client code to explicitly correlate the range</font></div><div><font face="Menlo">// that it initialized with the range that it deinitialized.</font></div><div><font face="Menlo">image.deinitialize(at: 0, count: filled) </font></div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Concerns:</div><div><br></div><div>## UnsafeMutablePointer</div><div><br></div><div>It&#39;s alarming that omitting `count` in `initialize(repeating:count:)` (and assign, etc.) means initialize _one_ element, but elsewhere (such as `UnsafeMutableBufferPointer` means initialize _all_ elements. The behavior of the proposed API also contradicts its own spelling on its face: `initialize(repeating: foo)` means *do not repeat* `foo`.</div><div><br></div><div>Yes, I understand the argument that `*BufferPointer` types have an intrinsic count, etc., but in the context of code where types are inferred, `let foo = T.allocate(capacity: 100); foo.initialize(repeating: bar)` should not mean one thing for `*BufferPointer` types and a totally different thing for plain `*Pointer` types--particularly when both can be allocated with a certain capacity greater than one.</div><div><br></div><div>Either `count` should always be required, or for convenience there should be a separate overload `initialize(pointee:)` that does not require `count`.</div><div><br></div></div></div></div></blockquote><div><br></div><div>I understand the naming is not optimal, but reams of discussion on this list have concluded that it’s the least bad alternative available. We can’t just get rid of the default value for `<span style="font-family:monospace,monospace">count:</span>` because usage in real code bases shows that this default argument is actually extremely useful. I believe well over 90% of the calls to these methods in the standard library currently rely on the default argument value. Renaming the `repeating:` argument to `to:` would make the API inconsistent and hide the fact that plain pointers are still capable of operating on many elements in sequence — “`<span style="font-family:monospace,monospace">to:count:</span>`” makes no grammatical sense to read — “to” is a singular preposition.</div></div></div></div></div></blockquote><div><br></div></span><div>The *only* thing I really don’t like about the proposed API is the potential confusion between UnsafeMutablePointer calls with a default count and UnsafeMutableBufferPointer calls using the implied buffer count. But this is where we ended up because the default count turns out to be useful. I’m willing to live with it since I don’t see a great alternative.</div></div></div></div></blockquote><div><br></div><div>This only thing is also the major thing that causes me concern. I have no problem with the name itself. In my view, it is important to provide the very useful function with a default count of 1 using a different name, as I&#39;ve written in the other reply.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span class=""><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>## UnsafeMutableRawBufferPointer</div><div><br></div><div>In `copyBytes`, the use of `Bytes` to emphasize that it&#39;s the memory that&#39;s being copied is thoughtful, but it is inconsistent with the other method names that use the terminology `Memory` for the same purpose (e.g., `moveInitializeMemory` to clarify the meaning of `moveInitialize`).</div><div><br></div><div>For better consistency--and since you&#39;re proposing to rename `copyBytes(from:count:)` on `UnsafeMutableRawPointer` to `copy(from:bytes:)`--this particular API on `UnsafeMutableRawBufferPointer<wbr>` should be named `copyMemory(from:)` and not `copyBytes(from:)`.</div><div><br></div><div>Although, actually, looking at the APIs on `UnsafeMutableRawPointer` itself, that particular method too might best be written as `copyMemory(from:bytes:)` instead of merely `copy(from:bytes:)` for better consistency with the rest of the methods on that type as well.</div></div></div></div></blockquote><div><br></div></div></div></div></blockquote><div><br></div></span><div>Xiaodi has a fair point. I’m a moderate +1 on his suggestion. I can’t remember why it wasn’t originally called “copyMemory”. Someone may have taken issue with the fact that it’s the contents of memory being copied, but that’s a silly distinction.</div><span class=""><div><br></div><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><div>“Memory” methods are distinct from “Bytes” methods in that they assume typed memory. “Bytes” on the other hand does not care about types.</div></div></div></div></blockquote><div><br></div></span><div>The other Memory methods take a type parameter out of necessity, but that doesn’t need to be a rule. The “Memory” suffix is there because the semantics of operating on untyped memory is slightly different. I think copyMemory would fit with that convention. After all, it’s really meant to be Swift&#39;s ‘memcpy’.</div><span class=""><div><br></div><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>## General comment</div><div><br></div><div><div>Many `at:` arguments, especially such as in the case of `copyBytes(at:from:)`, make sense only when read in a list with all other methods. Standing alone, `at` is ambiguous as to whether it&#39;s referring to the _source_ or the _destination_. Why do these APIs on `*BufferPointer` types not take advantage of subscripts? That is, why not:<br></div><div><br></div><div> <span class="m_6416729595521158717Apple-converted-space"> </span>`foo[x...].copyMemory(from: bar)`</div><div><br></div><div>instead of</div><div><br></div><div> <span class="m_6416729595521158717Apple-converted-space"> </span>`foo.copyBytes(at: x, from: bar)`</div><div><br></div><div>The first seems dramatically clearer as to its meaning. The same feedback applies to nearly all uses of `at` on `*BufferPointer` types: they would seem to be greatly clarified (in terms of the &quot;what does `at` mean&quot; question) by the use of a subscript spelling.</div></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div></span>In the proposed API, we have a consistent convention that some segment within potentially larger buffer is being replaced with the contents of a smaller buffer.<br><div><br></div><div>Ultimately, we want buffer slices to work the way you describe, but first we need to introduce new kind of buffer slice. That won’t happen in Swift 5. Our current buffer slices are fundamentally dangerous, and I don’t think it’s right to build convenience around danger.</div></div></div></div></blockquote><div><br></div><div>Got it. I think we&#39;ve circled back to the same conclusion here about the need for a new kind of buffer slice.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span class=""><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><div>This idea sounds elegant on the surface but it’s deeply problematic. `<span style="font-family:monospace,monospace">foo[x...]</span>` suggests that whatever happens to it, will happen to the entire rest of the buffer slice as well, which is not always the case. It would have to be written as `<span style="font-family:monospace,monospace">foo[x ... x + count].copyMemory(from: bar)</span>` or `<span style="font-family:monospace,monospace">foo[x ... x + bar.count].copyMemory(from: bar)</span>` which seems<span class="m_6416729595521158717Apple-converted-space"> </span><i>less</i><span class="m_6416729595521158717Apple-converted-space"> </span>clear.  Having to write `<span style="font-family:monospace,monospace">foo[0...]</span>` to operate with no offset also seems silly. It also means the API would have to be written on `<span style="font-family:monospace,monospace">MutableRandomAccessSlice&lt;<wbr>UnsafeMutable*BufferPointer&gt;</span>`. Finally, what happens when you subscript a raw pointer? the subscript doesn’t know about the stride that you want to use. If you want to get rid of the `<span style="font-family:monospace,monospace">at:</span>` ambiguity, you have to get rid of it everywhere, or users will just wind up having to remember two ways (one ambiguous and one less ambiguous) of doing the same thing, instead of one (ambiguous) way of doing it.</div></div></div></div></blockquote><div><br></div></span><div>Yes, Xiaodi is reopening this can of worms again. This is simply out of scope since the proposed API isn’t making any of these problems harder to solve in the future.</div></div></div></div></blockquote><div><br></div><div>It isn&#39;t making future solutions harder, but my concern is that the ambiguity of `at` and its use with different meanings (`at` in typed pointers referring to an offset that is a multiple of the *destination* pointee type, but `at` in raw pointers referring to an offset that is a multiple of the *source* pointee type instead of raw bytes) is confusing enough that designing a whole set of new methods to increase this usage is not clearly an improvement. At least, as compared to the status quo of tolerating the less ergonomic, but also unambiguous, `foo + MemoryLayout&lt;T&gt;.stride * offset`. Especially given that, as you say, these problems do need to be solved some other way in the future. Unless I am missing another major argument for incorporating additional uses of `at`, it would seem (to me) preferable to eliminate all or most of these uses entirely even if new slice types are out of scope for Swift 5.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span class=""><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>I notice that you comment that you feel there are ergonomic issues with buffer pointer slicing; can you please comment on what is &quot;wasteful&quot; currently? Is there a performance hit to slicing a `*BufferPointer` type? If so, we should fix that, as the whole rationale of having these types (as I understand it) is to improve the ergonomics of working with pointers to multiple elements by conforming them to `*Collection` APIs.</div></div></div></div></div></blockquote><div><br></div><div>Slices are not the right abstraction for this because of Swift’s indexing semantics. A buffer pointer requires two words of information (beginning and end address), while a buffer pointer slice occupies four words of information (beginning, end, start-index, end-index) to preserve the index semantics. Creating a way to “slice” a buffer pointer into another buffer pointer without going through `<span style="font-family:monospace,monospace">init(rebasing:)</span>` is also problematic because you can’t `<span style="font-family:monospace,monospace">deallocate()</span>` a debased buffer pointer, so we should make that operation explicit.<br></div></div></div></div></blockquote><div><br></div></span>Today’s buffer slices can certainly be useful when you want to expose a slice as a Sequence. They correctly refer back to the parent buffer and are exactly as efficient as they should be. You probably wouldn’t want to persistently store slices though. You’re better off rebasing the slice as a new buffer. When you do that it’s reasonably obvious that those rebased buffers don’t own their underlying memory. We can definitely come up with a better higher-level API, but there are bigger fish to fry.</div><div><br></div><div><span class=""><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>It seems deeply unsatisfactory to invent new methods that use `at:` arguments _on a type whose purpose is to expose `*Collection` APIs_ if we agree that the slicing notation is demonstrably clearer. I do not have the same concerns about adding `at:` arguments to `UnsafeMutableRawPointer` methods, which are quite appropriate.</div></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>The proposed new methods provide reasonable functionality on UnsafeBufferPointers when you’re *not* using collection APIs. A major motivation for this proposal is that to do anything low-level with an UnsafeBufferPointer, you currently need to drop down to an UnsafePointer first, which is hideous, and you lose bounds checking.</div><div><br></div><div>-Andy</div><div><div class="h5"><br><blockquote type="cite"><div dir="ltr" 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"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_6416729595521158717gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)"><li style="box-sizing:border-box;margin-top:0.25em">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></blockquote></span><div>Yes.</div><span class="m_6416729595521158717gmail-"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)"><li style="box-sizing:border-box;margin-top:0.25em">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></blockquote></span><div>In parts, yes. In others (see above), it could be improved to fit better with the feel and direction of other Swift APIs.</div><span class="m_6416729595521158717gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)"><li style="box-sizing:border-box;margin-top:0.25em">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li></ul></div></blockquote></span><div>There is much more friction to using pointers in Swift than in C. However, making Swift pointers like C pointers is clearly a non-goal. This proposal appropriate addresses major pain points to Swift-specific usages of pointers.</div><span class="m_6416729595521158717gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)"><li style="box-sizing:border-box;margin-top:0.25em">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></blockquote></span><div>A moderately thorough reading, drawing on some experience using pointer APIs in Swift, and based on prior readings of previous iterations of this proposal and the on-list discussion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_6416729595521158717gmail-"><div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)">More information about the Swift evolution process is available at</p><blockquote style="box-sizing:border-box;margin:0px 0px 16px;padding:0px 1em;color:rgb(106,115,125);border-left-width:0.25em;border-left-style:solid;border-left-color:rgb(223,226,229);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)"><div style="box-sizing:border-box;margin-top:0px;margin-bottom:0px"><a href="https://github.com/apple/swift-evolution/blob/master/process.md" style="box-sizing:border-box;background-color:transparent;color:rgb(3,102,214);text-decoration:none" target="_blank">https://github.com/apple/swift<wbr>-evolution/blob/master/process<wbr>.md</a></div></blockquote><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)">Thank you,</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)">-Doug</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&#39;Segoe UI&#39;,Helvetica,Arial,sans-serif,&#39;Apple Color Emoji&#39;,&#39;Segoe UI Emoji&#39;,&#39;Segoe UI Symbol&#39;;font-size:16px;background-color:rgb(255,255,255)">Review Manager</p></div><br></span>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br><br></blockquote></div><br></div></div><br>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br><br></blockquote></div><br></div></div><span 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;float:none;display:inline!important">______________________________<wbr>_________________</span><br 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"><span 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;float:none;display:inline!important">swift-evolution mailing list</span><br 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"><a href="mailto:swift-evolution@swift.org" 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" target="_blank">swift-evolution@swift.org</a><br 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"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" 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" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></blockquote></div></div></div><br></div></div></blockquote></div><br></div></div>