[swift-evolution] [Proposal idea] Support for pure functions

Alex Popov hello at alexpopov.ca
Mon Dec 21 16:04:41 CST 2015


Slight tangent, would a guarantee of purity also allow for more Tail-Call
Optimizations? A cursory glance at SO seems to point to TCO not always being
applied, especially when ARC is involved.

  

<br  
—

Alex Popov Jr.

Principal iOS Developer | Shelfie

> On Dec 21 2015, at 1:55 pm, Joe Groff via swift-evolution &lt;swift-
evolution at swift.org&gt; wrote:  
  

>

>> On Dec 21, 2015, at 1:49 PM, Chris Lattner via swift-evolution &lt;[swift-
evolution at swift.org](mailto:swift-evolution at swift.org)&gt; wrote:

>>

>>  

>>

>>  

>>

>>> On Dec 21, 2015, at 12:05 PM, Jacob Bandes-Storch
&lt;[jtbandes at gmail.com](mailto:jtbandes at gmail.com)&gt; wrote:

>>>

>>>  

>>>

>>> On Mon, Dec 21, 2015 at 11:55 AM, Chris Lattner via swift-evolution &lt
;[swift-evolution at swift.org](mailto:swift-evolution at swift.org)&gt; wrote:  

>>>

>>>> …there probably has to be some way to unsafely “force a call to a non-
pure function to be allowed in a pure one”, both because of type system
limitations as well as interoperability with C and other languages.  Even
ignoring issues around errno, it would be sad for a pure function to not be
able to call “sin(x)” just because it weren’t marked __attribute__((const)).

>>>

>>>  

>>>

>>> Minor tangent, but should the same apply to @noescape?

>>

>>  

>>

>> Yes, it should.  I believe you can currently use an unsafe cast to remove
@noescape, and that the stdlib does it in a few places.  Dmitri, do you know
where?

>

>  

>

> The runtime does this using unsafeBitCast, but don't follow its example—I
don't want to promise this will always be possible. There are representation
optimizations we can do with @noescape closures that would be blocked if they
always had to be bitcastable to refcounted escapable closures. I'd like to
introduce a `Builtin.makeEscapable` operation specifically to go from
@noescape to escapable, introducing a refcounting shim if necessary in the
future.

>

>  

>

> -Joe

>

> ![](https://u2002410.ct.sendgrid.net/wf/open?upn=CmwAv3oRa0AH4Hd1bWC6X-
2BzbhPqo1YEo6mPHEujr90vNqvSlNKW0iy2BTd4OxR0SCJAwyLx2cZ3twpk4M4WqgQG-
2FHUcfU2eLopRmdzTmpLuLZtOY1eD9WFERKSEU-2Fh8ZpSXZO8n-2FxFdugKSpD2tVIHo-
2B1Xm1Kx9Z6REnSigwhXQc1ZZ21GoUrVYCyW9mvlG9yTXA-2F8
-2BkRL3jMogyILA8zEwqIWg15KQWC24Bm6WqsLc-3D)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/276fa8be/attachment.html>


More information about the swift-evolution mailing list