I don't know very much about this topic, so I won't pretend that I have strong feelings about Michel's questions, but they are undeniably important and undoubtedly only one of many.<br><br>Before we get to any syntactic bikeshedding, can the proponents of this feature write up a comparative summary to educate us about the current state of the art? How have other languages have defined purity? I recall an earlier message about D, and some rough comparisons or non-comparisons to C++ constexpr. Roughly, it would be very helpful to get some sense of the following:<br><br>What other C-family languages have a concept of purity?<br><br>How is purity defined in those languages?<br><br>What use cases are enabled by those definitions of purity, and just as important, what use cases are notably excluded by them?<br><br>If there is evidence in the public record to this effect: if the designers of those languages could do it again, have they expressed any thoughts about how they would do it differently with respect to purity?<br><br>It has been said that Haskell and other functional languages prioritize purity over ergonomics of impure functions like I/O. With that in mind, what design choices surrounding purity made by those languages are off-limits for Swift?<br><br>What use cases or even compiler optimizations are possible in Haskell and other non-C family languages with a more expansive or stricter concept of pure functions that we don't find in C-family languages?<br><br>If Swift were to adopt some of these beyond-C rules, how would that impact the user experience with common impure functions (I/O, etc.)?<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 19, 2017 at 14:45 T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">I'm going to update the draft with points addressed here and the twitter conversation. There have been quite a few implications to consider pointed out. <div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This feature is not 'for' the compiler as much as it is for humans writing code, but I will address that in the update.</div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Sun, Feb 19, 2017 at 3:34 PM, David Sweeris <span dir="ltr" class="gmail_msg"><<a href="mailto:davesweeris@mac.com" class="gmail_msg" target="_blank">davesweeris@mac.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"></span></div><div class="gmail_msg"><span class="gmail_msg"><span class="gmail_msg"></span><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><span class="gmail_msg">On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</span><br class="gmail_msg"></blockquote><blockquote type="cite" class="gmail_msg"><span class="gmail_msg"></span><br class="gmail_msg"></blockquote><blockquote type="cite" class="gmail_msg"><span class="gmail_msg">7. Is it desirable that the optimizer sometime take the pure attribute to heart to combine multiple apparently redundant calls into a single one? Or is pure not intended to be usable for compiler optimizations? The ability to optimize will likely be affected by the answer to these question and the loopholes you are willing to allow.</span><br class="gmail_msg"></blockquote><span class="gmail_msg"></span><br class="gmail_msg"></span><span class="gmail_msg">AFAIK, "compiler optimizations" are main point of having a keyword for pure functions. (Well, that and whatever role it might play in supporting constant expressions, but that seems like more of a compiler implementation detail than an actual "feature" of pure functions.)</span><br class="gmail_msg"><span class="gmail_msg"></span><br class="gmail_msg"><span class="gmail_msg">Calling fatalError() is fine IMHO because, at that point, any side-effects become a moot point.</span><br class="gmail_msg"><span class="gmail_msg"></span><br class="gmail_msg"><span class="gmail_msg">I'm inclined to say that passing in reference values is ok, as long as we can prove the function doesn't modify anything. Don't know how we'd do that, though, since classes don't need that `mutating` keyword for functions that mutate `self`.</span></div><div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg">If someone is determined to use pointers to pointers to get global state or something to trick the compiler into accepting <i class="gmail_msg">semantically</i> impure code as <i class="gmail_msg">syntactically</i> pure, I'm not sure there's a way we can really stop them. Not and still have @pure be useful. (Or maybe we can... I'm merely thinking of the saying, "every time someone builds a fool-proof system, the world makes a bigger fool".)<br class="gmail_msg"><br class="gmail_msg">I would think that allocating memory is ok, as long as it's either deallocated by the time the function exits or it's part of the return value, but I don't know a lot about low-level implementation details, so maybe there's something I'm missing. If that is a problem, though, I think the answer to your "what subset..." question would, more or less, be whatever subset doesn't rely on the runtime (the usefulness of that subset should expand if/when we extend the syntax around tuples or support fixed-length arrays in some other way).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In any case, yeah, IMHO you're correct that we should nail down the semantics before worrying so much about the syntax.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Dave Sweeris</div></div></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>