<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="">The breakdown of purity in D is very interesting. In D, a pointer that is marked as constant means the memory it points to is considered constant. One of the issues raised is that Swift does not have that “transitive immutability”, which limits what the compiler can infer. I can see how that would be tricky. <div class=""><br class=""></div><div class="">But is supporting reference types really necessary here? You can get a lot done in Swift using only structs, enums, and protocols, which all support value semantics. If we want to have a pure function act on the values in a reference type, you can just write "someObject.member = someFunc(someObject.member)"<div class=""><br class=""></div><div class="">There’s also the split opinions on whether this keyword would be most useful for communicating intent to the reader of the code, or performing compiler optimizations. I’m very firmly in the former camp. From my point of view compiler optimizations are just gravy.<br class=""><div class=""><br class="webkit-block-placeholder"></div><div class="">There are also syntactic disagreements, but as someone mentioned, getting too attached to a particular syntax is probably just bikeshedding at this stage.</div></div></div><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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; display: inline !important; float: none;" class="">Sent from my Mac</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2017, at 6:57 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">This is a topic of considerable history. See:</div><div class=""><br class=""></div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003684.html" target="_blank" class="">https://lists.swift.org/<wbr class="">pipermail/swift-evolution/<wbr class="">Week-of-Mon-20151214/003684.<wbr class="">html</a><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/003900.html" target="_blank" class="">https://lists.swift.org/<wbr class="">pipermail/swift-evolution/<wbr class="">Week-of-Mon-20151221/003900.<wbr class="">html</a></div><div class=""><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006005.html" target="_blank" class="">https://lists.swift.org/<wbr class="">pipermail/swift-evolution/<wbr class="">Week-of-Mon-20160104/006005.<wbr class="">html</a></div><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/027010.html" target="_blank" class="">https://lists.swift.org/<wbr class="">pipermail/swift-evolution/<wbr class="">Week-of-Mon-20160905/027010.<wbr class="">html</a></div><div class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032076.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032076.html</a></div><div class=""><br class=""></div><div class="">It would be important for those who wish to rekindle this discussion first to review and summarize the preceding, and very technically illuminating, discussions.</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="gmail_extra"><div class="gmail_quote">On Thu, May 25, 2017 at 5:39 PM, Michael Savich via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Writing functions without side effects is generally considered to result in less error-prone code. In Swift today, if you want to segment your code into pure and impure functions, you just have to police yourself, which is a very un-Swifty thing to have to do. This problem is compounded when working in teams, where someone else of course won’t know which of your functions are pure, and even if you leave a comment it’s not a guarantee they’ll know (or care) what “pure” means.<br class="">
<br class="">
So what about adding the ability to annotate functions with a special keyword? For example "pure func addTwoNums(n1: Int, n2: Int)”.<br class="">
The rule here is very simple: functions annotated with “pure” can only call other functions annotated with “pure”, otherwise the compiler produces an error.<br class="">
<br class="">
To me, this feels like a very natural fit for Swift. What does everybody else think?<br class="">
______________________________<wbr 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/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
</blockquote></div><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></body></html>