[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 <swift-
evolution at swift.org> wrote:
>
>> On Dec 21, 2015, at 1:49 PM, Chris Lattner via swift-evolution <[swift-
evolution at swift.org](mailto:swift-evolution at swift.org)> wrote:
>>
>>
>>
>>
>>
>>> On Dec 21, 2015, at 12:05 PM, Jacob Bandes-Storch
<[jtbandes at gmail.com](mailto:jtbandes at gmail.com)> wrote:
>>>
>>>
>>>
>>> On Mon, Dec 21, 2015 at 11:55 AM, Chris Lattner via swift-evolution <
;[swift-evolution at swift.org](mailto:swift-evolution at swift.org)> 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