<div dir="ltr">On Thu, Sep 1, 2016 at 1:48 PM, Andrew Trick <span dir="ltr">&lt;<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>&gt;</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 style="word-wrap:break-word"><div><div class="gmail-h5"><br></div></div><div>Also, in the first case the UnsafePointer points to local memory that holds the function value. In the second case, you’re trying to load a function value from the address of the function body.</div><div><br></div></div></blockquote><div> </div><div>Beginning to see...</div><div><br></div><div>On Fri, Sep 2, 2016 at 9:49 AM, Jordan Rose <span dir="ltr">&lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt;</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 style="word-wrap:break-word"><span class="gmail-"><br></span><div>I feel like there’s still one last piece missing here, which is that in Swft a &quot;function-typed value” is not the same as a “function pointer” in C. Because a function value might have come from a closure, it might include captured state…so the representation of a closure is not the same as a representation of a plain function.</div><div><br></div><div>Because of <i>that</i>, the address you’re seeing isn’t the address of the function in memory; it’s the address of the temporary allocation used to represent “this global function and no associated state”. That’s why you can’t just form a pointer with that bit-pattern and expect it to work.</div><div><br></div></div></blockquote><div><br></div><div>Seeing!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hope you’ve gotten some useful information between the three of us. :-)</div></blockquote><div><br></div><div>That&#39;s the trifecta of support right there!  Thank you all! </div><div><br></div><div>I ran a new little experiment for the curious:</div></div><div>







<p class="gmail-p1">var a: () -&gt; () = {<br>
<span class="gmail-s1">    </span>print(&quot;foo!&quot;) <br>
}  <br><font color="#999999">
a: () -&gt; () = 0x0000000100561080 $&lt;snip&gt; at repl2.swift</font><br>
withUnsafePointer(&amp;a) {$0}<br><font color="#999999">
$R0: UnsafePointer&lt;() -&gt; ()&gt; = 0x00007fff5fbffce8</font><br>
<br>
UnsafePointer&lt;() -&gt; ()&gt;(bitPattern: 0x00007fff5fbffce8)!.pointee()<br><font color="#999999">
// foo!</font><br>
UnsafePointer&lt;() -&gt; ()&gt;(bitPattern: 0x0000000100561080)!.pointee()<br><font color="#999999">
// Crashes as expected!</font></p><p class="gmail-p1">And: <br></p><p class="gmail-p1">







</p><p class="gmail-p1">typealias MyType = @convention(c) () -&gt; ()<br>
var b: MyType = { <br>
<span class="gmail-s1">    </span>print(&quot;bar!&quot;) <br>
} <br><font color="#999999">
b: __lldb_expr_10.MyType = 0x000000010056<span style="background-color:rgb(0,255,0)">b150</span> $&lt;snip&gt; at repl12.swift</font><br>
withUnsafePointer(&amp;b) {$0}<br><font color="#999999">
$R1: UnsafePointer&lt;__lldb_expr_10.MyType&gt; = 0x000000010056<span style="background-color:rgb(0,255,0)">4c80</span><br></font>
<br>
UnsafePointer&lt;MyType&gt;(bitPattern: 0x0000000100564c80)!.pointee()<br><font color="#999999">
// bar!</font><br>
UnsafePointer&lt;MyType&gt;(bitPattern: 0x000000010056b150)!.pointee()<br><font color="#999999">
// Crash!</font><br>
</p><p class="gmail-p1">I am surprised to find here that the addresses are different, albeit much closer in space than the first example. I suppose there&#39;s still some swift machinery at work to make a function type declared as @convention(c) to _behave_ as a function pointer.  Cool.<br></p><p class="gmail-p1">Thanks again Quinn, Andy, Jordan!</p></div></div>