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- [email protected]> wrote: > >> On Dec 21, 2015, at 1:49 PM, Chris Lattner via swift-evolution <[swift- [email protected]](mailto:[email protected])> wrote: >> >> >> >> >> >>> On Dec 21, 2015, at 12:05 PM, Jacob Bandes-Storch <[[email protected]](mailto:[email protected])> wrote: >>> >>> >>> >>> On Mon, Dec 21, 2015 at 11:55 AM, Chris Lattner via swift-evolution < ;[[email protected]](mailto:[email protected])> 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 > > 
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
