<div dir="ltr"><span name="品雪" class="" style="font-size:13px">Hi 品雪</span><font color="#555555"><span style="white-space:nowrap">,</span></font><br><div><font color="#555555"><span style="white-space:nowrap"><br></span></font></div>As I understand Howard's intentions @pure and @impure are just antonyms, like true versus false. The important distinction is that if we only had a @pure keyword then functions are allowed to be impure by default, which is easier for existing code and probably beginner programmers. Functions are not checked for purity unless annotated.<div><br></div><div>C and Objective-C may be able to be marked as pure in future, but I think it's too difficult to do so at the moment. It's probably the case that there will be some kind of import attribute that could allow c functions to be marked as pure for the standard library, however I doubt there will be any automated checking.</div><div><br></div><div>"no-side-effects" is essentially the same. It's mainly a matter of defining what side-effects are and are not allowed. Side-effects could mean that it doesn't take any processor time, or it doesn't change registers, or cannot abort execution, allocate memory, etc.<br></div><div><br></div><div>Andrew</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 9, 2016 at 8:59 PM, 品雪 <span dir="ltr"><<a href="mailto:pinxue@gmail.com" target="_blank">pinxue@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So what's the semantic difference between @pure and @impure type?<div><br></div><div>"<span style="font-size:13px">c and objective-c would not be marked as pure." </span>It sounds like pure swift.</div><div><br></div><div>"Pure functions can be safely removed by the optimizer if their result is not used. " It sounds like no-side-effects or immutable.<br></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Sat, Jan 9, 2016 at 5:14 PM, Howard Lovatt via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Comment in-line below.<div><br><div><span><blockquote type="cite"><div>On 9 Jan 2016, at 8:04 PM, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" target="_blank">cacoyi@gmail.com</a>> wrote:</div><br><div><div dir="ltr">That would be nice, although I'm not sure how practical that is in current swift usage. I imagine it would require a lot of changes to existing code and libraries.</div></div></blockquote><div><br></div></span>Not sure how hard this would be or if a migration tool and enhanced Obj-C importer would be good enough.</div><div><span><br><blockquote type="cite"><div dir="ltr"><div>Is a method impure if it uses self? I suppose it could be. I guess self is an inout parameter. I presume an inout parameter is a known expected side-effect.</div></div></blockquote><div><br></div></span><div>If it doesn’t change self then it is pure.</div><span><br><blockquote type="cite"><div dir="ltr"><div>Closures would probably be the largest impact if things were pure by default.</div></div></blockquote><div><br></div></span>I think this would be a great change. We are part way there with @noescape and @autoclosure already</div><div><span><br><blockquote type="cite"><div dir="ltr"><div>It would be interesting though to do a code survey and see what portion would need to be marked as @impure, and what conditions lead them to that requirement.</div><div><br></div><div>I'm happy to discuss @impure too, but my focus is still @pure, as I think it is a more attainable target, at the moment.</div><div><br></div><div>Perhaps after everything is annotated, impure functions are minimised, and if swift is streamlined for pure function use, then we can introduce @impure and deprecate @pure.</div></div></blockquote><div><br></div></span>Not sure either will happen any time soon :(. Therefore the most useful thing would be the survey you suggest.</div><div><div><div><br><blockquote type="cite"><div dir="ltr"><div>On Sat, Jan 9, 2016 at 7:56 PM, Howard Lovatt <span dir="ltr"><<a href="mailto:howard.lovatt@gmail.com" target="_blank">howard.lovatt@gmail.com</a>></span> wrote:</div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I would rather you mark a function as impure and have the default as pure!<div><br><br><br>
</div>
<br><div><blockquote type="cite"><div><div><div>On 9 Jan 2016, at 7:53 PM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr"><div>I'd like to discuss adding a @pure keyword, and see what it requires and how possible it is to include.</div><div><br></div>I'd like to use the annotation @pure on functions, methods and closures.<div><br></div><div>This will allow us to make more guarantees about what a protocol does, and what it cannot do. It will also allow APIs like `.map` and `.forEach` to have a meaningful distinction. It could also allow for something like an assert to be removed as an optimisation with no side-effects in a release build.</div><div><div><br></div><div>If something is pure it can be annotated with @pure, if it is not-pure this will be a compile-time error. The compiler could automatically add this annotation in the interface.</div><div><br></div><div>A function, method or closure is pure if:</div><div> * all functions, methods and closures it calls are also pure (this includes referencing self from a method or property)</div><div> * it only externally references let variables of pure type, let properties on those variables, and methods/computer-properties marked as pure.</div><div><br></div>A computed property can be marked as pure like this:<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>@pure var test: A</div></blockquote><div><br>A function/method/closure signature is marked as pure like this:<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">(a: A, b: A -> B) @pure -> B</font></div></blockquote><div><br></div><div>If the function/method/closure is only pure if an argument is pure (similar to @rethrows), then you could do this:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span style="font-family:monospace,monospace">(start: A, a: A -> B) @pure(b) -> B</span></blockquote><div><span style="font-family:monospace,monospace"><br></span></div><div><font face="arial, helvetica, sans-serif">Potentially this could be extended to allow a pure closure to be composed of other pure closures:</font></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:monospace,monospace">func compose(a: A -> B, b: B -> C) @pure -> A </span><span style="font-family:monospace,monospace">@pure(a,b) </span><span style="font-family:monospace,monospace">-> C {</span></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:monospace,monospace"> return { b(a($0)) }</span></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:monospace,monospace">}</span></div></blockquote><div><div><div><br></div></div></div><div>Of course this doesn't preclude you from requiring some of those closures to be pure:</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span style="font-family:monospace,monospace">func compose(a: A @pure -> B, b: B -> C) @pure -> A </span><span style="font-family:monospace,monospace">@pure(b) </span><span style="font-family:monospace,monospace">-> C {</span></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span style="font-family:monospace,monospace"> return { b(a($0)) }</span></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span style="font-family:monospace,monospace">}</span></blockquote></div><div><br></div><div><div>Impact on existing code:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">No negative impact as if automatic annotation was allowed it would only happen where it was safe to do so. If it was not allowed then libraries could be slowly annotated to be marked as pure.<br><br>c and objective-c would not be marked as pure.<br><br>Pure functions can be safely removed by the optimiser if their result is not used. From this perspective assert and print should not be marked as pure (they would have to be an exception anyway).<br><br>Ideally existing libraries would be annotated, the more the better, but this can be a gradual process.<br><br><br></blockquote></div><div><br></div></div></div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Vm9j-2B2K6zLqxUFTO82XA8HV2TThDz5lA3-2F-2Fpeujw7DSrVPnP3caZaVllbVBnz-2FZs1lAXgswDGxkSarVozl8lyWwpPF5NgqEXdLRmAHjS2gijoNKbKYUO9axCjMjWNwocOJg2jPcqG7WpLnASa-2F2cre0HzP3TdnfdbaYjGyNu-2BAdejzv9cwJLF6aK78a0EoiFsQ7wRpeC0gu9o7W6uOyEZu5s9qW-2Fp2mdFuDD-2FAbATF4-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=zv-2Fta8zZnJ-2BWwISX5RHdd79su-2FjoebtLz43a4s-2BYOw3Qq3U20hlz4XsVzyvC64PeYWwW56VCztCpqpdIxHq8ZPED2a-2F8Wg7vPEvNgDgwZt6nkQz7r1-2BeGUtAhJiIiC78gBTiZ9aTLDWoyEr24R3UQz2ERQXrW6ct-2F8r6TXj-2FPIsjAVt41CxZ6B0cYVNq37LDt0vQ8IcJZ6QBJOZWVbM9QA0lORADwRM-2F-2FtZI8mGWQwk-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Best Regards!<br><br>Yang Wu<br>--------------------------------------------------------<br>Location: Pudong, Shanghai, China.<br>EMail : <a href="mailto:pinxue@gmail.com" target="_blank">pinxue@gmail.com</a><br>Website: <a href="http://www.time2change.mobi" target="_blank">http://www.time2change.mobi</a> <a href="http://rockplayer.com" target="_blank">http://rockplayer.com</a><br>Twitter/Weibo : @pinxue<br><a href="http://www.pinxue.net" target="_blank"></a></div></div>
</font></span></div>
</blockquote></div><br></div>