<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div name="messageBodySection" class="">But given the scope capturing nature of closures I was actually wondering if this 'purity' should be applied to closures.<br class=""></div></div></blockquote></div>I think It should, pure closure cannot have outside references and therefore cannot create reference cycles even though they are escaping.<div class=""><br class=""><div class="">I tend toward using the => sign since it doesn't require a lot of change, it has a nice lightweight syntax and seems different enough from -> .</div><div class="">The pure keyword in front of the function signature looks like a lot of noise for such a simple concept. And It will only get worse in function signatures.</div><div class=""><br class=""></div><div class="">see the difference between </div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> pureCurryCompose<A, B, C>(f: </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">@pure</span><span style="font-variant-ligatures: no-common-ligatures" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">B</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">C</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="color: rgb(186, 45, 162);" class="">@pure</span><span style="font-variant-ligatures: no-common-ligatures;" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">@pure</span><span style="font-variant-ligatures: no-common-ligatures;" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">A</span><span style="font-variant-ligatures: no-common-ligatures;" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">B</span><span style="font-variant-ligatures: no-common-ligatures;" class="">) -> (</span><span style="color: rgb(186, 45, 162);" class="">@pure</span><span style="font-variant-ligatures: no-common-ligatures;" class="">(</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">A</span><span style="font-variant-ligatures: no-common-ligatures;" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">C)</span></div></div><div class=""><br class=""></div><div class="">and </div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> pureCurryCompose<A, B, C>(f: (</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">B</span><span style="font-variant-ligatures: no-common-ligatures" class="">) => C) => ((A) => B) => (A) => C</span></div></div><div class=""><br class=""></div><div class="">The second is easiest to read.</div><div class=""><br class=""></div><div class="">(of course I would argue that </div><div class=""><span style="font-family: Menlo; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class=""><br class=""></span></div><div class=""><span style="font-family: Menlo; font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">func</span><span style="font-family: Menlo; font-variant-ligatures: no-common-ligatures;" class=""> pureCurryCompose<A, B, C>(f: </span><span style="font-family: Menlo; font-variant-ligatures: no-common-ligatures; color: rgb(79, 129, 135);" class="">B</span><span style="font-family: Menlo; font-variant-ligatures: no-common-ligatures;" class=""> => C) => (A => B) => (A => C</span>) </div><div class=""><br class=""></div><div class="">is the most readable of all but I'm too late for that proposal )</div></div></div></div></blockquote><br class=""></div><div>I don’t think it’s worth burning an operator for this (especially since the ones that are visually similar to “->” and “=“ are likely to be used by people trying to “wrap” functions or assignment).</div><div><br class=""></div><div>I’m also currently -1 on the idea of giving some attributes special syntax… What happens when we decide some other attribute is worth adding? Does, say, “distributive" get to be written as “func * (x:Foo, y:Foo) %> Foo”? How would we denote a function that’s both “pure” and “distributive”? “func * (x:Foo, y:Foo) %~> Foo”? That gets real hard to read (and eats up large swathes of operators) real fast.</div><div><br class=""></div><div>- Dave Sweeris</div></body></html>