<div dir="ltr">UnsafeBufferPointer is currently represented as a (nullable) C pointer plus size. It can be implemented almost in pure Swift (with calls to C functions).<div><br><div>After the proposal is accepted, it will be replaced with Optional&lt;UnsafeBufferPointer&gt;. But it will require a compiler-only &quot;hack&quot; for Optional not to require extra memory for nil (I assume, Optional will look into address part of UnsafeBufferPointer). This symbiosis will have to be built in the compiler, and I call that &quot;compiler magic&quot;.</div><div><br></div><div>The need for such magic is an argument for unified UnsafeBufferPointer to be more &quot;natural&quot;. I&#39;m not going to say that this argument will seem strong for everyone, though.</div><div><br></div><div>For that last statement, I was trying to say that we wouldn&#39;t need to invent special value for &quot;empty&quot; UnsafeBufferPointer if we left everything as it is now.</div><div><br></div><div>Also I agree that this change will be positive for use of *Pointer strictly inside Swift. It is mainly interaction with C that will become more verbose.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-28 20:45 GMT+03:00 Jordan Rose <span dir="ltr">&lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt;</span>:<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"><span class=""><br><div><blockquote type="cite"><div>On Mar 26, 2016, at 9:15, Антон Жилин via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style: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">But we currently have a terser form, and it&#39;s arguably clear from it that Pointer can be null.</span></div></blockquote></div><br></span><div>For the record, I literally talked to someone last week who didn&#39;t know that UnsafePointer can be null. :-) They thought we&#39;d already implemented this and there was a bug in the importer.</div><span class=""><div><br></div><div><div><blockquote type="cite">Overall, separating strongly connected concepts and then tying them together using compiler magic just can&#39;t have a reasonable explanation. ~0x0 in UnsafeBufferPointer is utterly rediculous.</blockquote></div></div><div><br></div></span><div>I&#39;m not sure what this comment refers to. Can you explain?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Jordan</div></font></span></div></blockquote></div><br></div>