[swift-evolution] [Proposal idea] Support for pure functions
cacoyi at gmail.com
Sat Jan 9 23:41:00 CST 2016
I started another thread on @pure in swift, luckily Chris Lattner reminded
me about this one. I'm going to continue any discussion here so we don't
fragment the conversation.
The other thread was a pre-proposal discussion called "Proposal proposal:
@pure keyword", it isn't archived so I cannot link it.
I've summarised the progress so far here (it's in the proposals directory
If I've missed anything or you want to update, clarify, fix typos, etc.
please submit a PR :) I'm trying to keep it focused on things that have
I've tried to unify the ideas from both the other thread and this one into
that summary. As it's not really a proposal I haven't included the
excellent justifications that Jimmy initially stated, they can be added if
it becomes a proposal. Please add a PR if you would like them there.
On Tue, Dec 22, 2015 at 9:08 AM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:
> > On Dec 21, 2015, at 2:04 PM, Alex Popov via swift-evolution <
> swift-evolution at swift.org> wrote:
> > 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.
> I don't think any reasonable meaning for `pure` in Swift would affect the
> possibility of TCO. There was another thread about TCO here you might read
> back on; as I explained there, ARC is not a barrier to TCO, our ownership
> and machine-level calling conventions are. We would need to be able to use
> a specific calling convention for guaranteed-TCOable entry points.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution