[swift-evolution] [Proposal idea] Support for pure functions
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.
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution