<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I am very much in support to of a @pure decorator. It could unlock a new level of performance for Swift and make everything safer. <div class=""><br class=""></div><div class="">For the issue of essentially pure functions that cannot be statically validated as pure (due to calling external code etc, as described by many in this thread), I think that one way to solve it would be to use a decorator along the lines of @pure(unsafe). This decorator would mean that the compiler should treat this function as pure, ‘trusting’ the programmer.</div><div class=""><br class=""></div><div class="">- T. </div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Jan 2016, at 22:27, Jimmy Sambuo via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Thanks Andrew and everyone for your ideas and inputs.<div class=""><br class=""></div><div class="">Andrew, your summary is amazing. It covers so many non-trivial cases of this feature.</div><div class="">I believe this is the archive of the other thread:<span class="Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006005.html" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006005.html</a><br class=""></div><div class=""><br class=""></div><div class="">I was hesitant to add more to this discussion because I was only able to think of the trivial case, and I know this can have lots of hidden complexities and implications. Looking at Andrew's summary gave me some ideas for talking points. Specifically, the section with inout parameters and pure mutating functions seems strange to me as I wasn't expecting mutation to occur, but this may be a valid scenario for "weakly pure" functions, where parameters can be modified.</div><div class=""><br class=""></div><div class="">Chris had mentioned that there probably should be some way to <span style="font-size: 12.8px;" class="">to unsafely "force a call to a non-pure function to be allowed in a pure one," and that </span><span style="font-size: 12.8px;" class="">it would probably make sense as an attribute @pure instead of a declmodifier. Perhaps this is another form of "weakly pure" functions. I'm thinking in this case, pure is acting as a marker, the type system does not have to know about actual purity and an effects system would not have to be implemented in this case. This should make implementation simpler and less invasive to the existing type system.</span></div><div class=""><span style="font-size: 12.8px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.8px;" class="">Imagine if ! was used to call an impure function within a pure function:</span></div><div class=""><span style="font-size: 12.8px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.8px;" class="">```swift</span></div><div class=""><span style="font-size: 12.8px;" class="">/// Wrapper around C sin()</span></div><div class=""><span style="font-size: 12.8px;" class="">func sin(x: Double) @pure -> Double {</span></div><div class=""><span style="font-size: 12.8px;" class=""> return sin(x)!</span></div><div class=""><span style="font-size: 12.8px;" class="">}</span></div><div class=""><span style="font-size: 12.8px;" class="">```</span></div><div class=""><span style="font-size: 12.8px;" class=""><br class=""></span></div><div class=""><span style="font-size: 12.8px;" class="">In my mind, seeing ! tells me something could be wrong there so pay closer attention. I would think `sin` is a C function so Swift doesn't know it should be pure, but sine is a math function so it should be safe. What about for actually impure functions? Optionals and try! crashes when expectations are not met. Should `potentiallyImpureFunc()!` or `mostlyPureFunc()!` crash if an "impure" value or side effect occurs? How would the runtime know this if purity is defined by annotations? Maybe it shouldn't crash, but now ! is slightly different from optionals and try!. Perhaps there should be a different symbol for "unwrapping" impure functions. Then there would be two different symbols for unwrapping.</span></div><div class=""><br class=""></div><div class=""><span style="font-size: 12.8px;" class="">My major concern is I'd want to avoid a situation where developers are adding @pure and unwrapping impure functions just to make their app compile, making @pure meaningless since most of their pure functions will actually be impure. I'm not sure of a good way to prevent this.</span></div><div class=""><br class=""></div></div><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="gmail_quote">On Sun, Jan 10, 2016 at 12:41 AM, Andrew Bennett via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The other thread was a pre-proposal discussion called "Proposal proposal: @pure keyword", it isn't archived so I cannot link it.</div><div class=""><br class=""></div><div class="">I've summarised the progress so far here (it's in the proposals directory for convenience):</div><div class=""><br class=""></div><div class=""><a href="https://github.com/therealbnut/swift/blob/therealbnut-pure-preproprosal/docs/proposals/PureKeyword.rst" target="_blank" class="">https://github.com/therealbnut/swift/blob/therealbnut-pure-preproprosal/docs/proposals/PureKeyword.rst</a></div><div class=""><br class=""></div><div class="">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 little contention.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><div class=""><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Dec 22, 2015 at 9:08 AM, Joe Groff via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class=""><br class="">> On Dec 21, 2015, at 2:04 PM, Alex Popov via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">> 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 class=""><br class=""><br class=""></span>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.<br class=""><br class="">-Joe<br class=""><div class=""><div class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nCigty3f1lpVtTdtXLf27rKWzt-2FQNpAdFrHTP2CgQfcEXdP1XrcbLV8nj8B-2FtLoIhR2Jtyr6QNrodSpraBgJZ7MBAlMc2kGuCmLmvPFm2Xmd6H17KiUQULnWU1aFaDthPdvZvXimQ9ragliau4vlAW33QSstCQxuDdj1ucR5eIc3YeJ0JtBHIW6xs2uCVi-2FgbY6Gj4uCCNXDlyOv5ciYFfWJCcRWRc7-2Ba1bMdFoSnbo-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span class="Apple-converted-space"> </span><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature">Jimmy Sambuo<br class=""><a href="http://www.sambuo.com/" target="_blank" class="">www.sambuo.com</a></div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=x4DBtcYZPuS8wt8fMTVYDXzwU9szxEmdHE1DwQfVzUfwrRnrRnGhJS1lApRTXzTDL5ba7-2F2sztrr2h-2FTFZfaRJy05yVrT8H43BvrvJ7ohoXmKe1Wfn03TjuGDt7NwseykdJNwktENWajfclApIuWmxQxsxVZsncAu5fKG93by0-2FVlwJMGus291x4j59ex-2FBACaIJUxW9PfZrTLry0ouT-2FhSZ4opOSJgN9XGfZNV5vFI-3D" alt="" width="1" height="1" border="0" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></div></body></html>