<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman <span dir="ltr">&lt;<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>&gt;</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><span class=""><blockquote type="cite"><div>On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_8838718759258939183Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Aug 20, 2017, at 6:03 PM, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt; wrote:</div><br class="m_8838718759258939183Apple-interchange-newline"><div><div dir="ltr"><div>New draft of the proposal is up here: &lt;<a href="https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md" target="_blank">https://github.com/kelvin13/<wbr>swift-evolution/blob/patch-3/<wbr>proposals/0184-improved-<wbr>pointers.md</a>&gt;<br><br></div>Important changes <a href="https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md#proposed-solution" target="_blank">start here</a>.<br></div></div></blockquote><div><br></div><div>This should be brought to the attention of swift-evolution:</div><div><br></div><blockquote type="cite">The old `deallocate(capacity:)` <wbr>method should be marked as `unavailable` since it currently encourages dangerously incorrect code. This avoids misleading future users, forces current users to address this potentially catastrophic memory bug, and leaves the possibility open for us to add a `deallocate(capacity:)` <wbr>method in the future, or perhaps even a `reallocate(toCapacity:)` <wbr>method.<br></blockquote><div><br></div><div>I can’t defend breaking existing source without having seen real code that was actually written incorrectly. I don’t see the downside of using the same deprecation strategy as the other changes. I expect code that was already written to be correct and future code to not call the deprecated API.</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are you arguing it should remain deprecated or can it become obsoleted?</div></div></div></blockquote><div><br></div><div>I mean I just thought that it would be best to get rid of this as quickly and harshly as possible because a lot of people might think their code was correct when in fact it wasn’t (the example in the document is biased to segfault but if the lengths are smaller, a segfault might not occur, even though invalid access is still being done.) <br></div></div><br></div></div>