<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Dec 21, 2015, at 12:20 PM, T.J. Usiyan 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="">I have been thinking about this proposal since the list opened up. I think that @read(none|only) should be considered as an alternative. Just as in clang and the optimizer annotations @read(none) would be the attribute described and @read(only) could read global variables but could not write. Is it possible to generate a runtime error if we guarantee that function A is pure, only to call it and 'find out' that it isn't? If we can, then do try syntax could be considered. </div></div></blockquote></div><br class=""><div class="">Another approach here is an effects system. If a pure function were spelled `(T) => U`, then `readonly` could be expressed as `(T) reads => U`, and (T) -> U could remain as a synonym for (T) reads, writes => U, in the spirit of encouraging immutability without punishing mutability.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>