<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=""><div class="">I definitely see where John is coming from, but my intuition (which I have to agree is of arguable worth) is telling me that it’s a good direction to explore. I believe that the current system is broken, even if the degree of this is not significant, and doesn’t affect most uses. As the language matures, and the use of error-throwing with a more functional style of programming becomes more prevalent, I think that some form of advance in the matching system will have to be made.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Here’s my perspective on this: (Disclaimer: I’m having a bit of trouble getting my head around the compiler, and exactly how “rethrows" and type unification work.)</div><div class=""><br class=""></div><div class="">* I’m very fond of the availability of rethrows as a function declaration annotation, it’s very clear in its requirements and in its guarantees. By allowing it to be a type annotation, these same contracts can be used by the readers of the code, and by the compiler.</div><div class="">(For example, a function is throwing iff there is a reachable, uncaught, throwing expression; a function is rethrowing iff it is not throwing and there is a reachable, uncaught, call to a function, taken as input, that is marked as throwing. This may or may not be useful to the compiler, but it would definitely help me when dealing with throwing code.)</div><div class=""><br class=""></div><div class="">* Dmitri’s suggestion of making the compiler advanced enough to have the rethrows generated automatically doesn’t seem to be any less complicated than requiring the programmer to add it to the function type by hand. I’m also not entirely sure how it would work in a context where you declare that a function with rethrowing semantics is expected. Maybe I just missed the point of the comment entirely.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">— Sasha</div><div class=""><br class=""></div><div class="">P.S. &nbsp;Is there documentation somewhere of the rules by which types are unified today, and of the way that "rethrows" is currently handled, or should I just keep working at reading the code?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 22 Dec 2015, at 20:41, John McCall &lt;<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>&gt; 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="">On Dec 21, 2015, at 6:09 PM, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">John, IIRC you had some reason why this wasn't a great idea, but I can't remember it. It seems useful to me too, if not something that comes up <i class="">too</i>&nbsp;often.</div></div></div></blockquote><div class=""><br class=""></div>I don’t remember off-hand. &nbsp;I think it’s theoretically supportable, but it adds extra complexity to the type system that I wanted to avoid if possible.</div><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2015, at 2:46 , Alexandre Lopoukhine via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Dmitri,<br class=""><br class="">This is a better example than any that I have come up with so far as to why “rethrows” should be a part of the signature. You shouldn’t have to use “try!” to apply a non-throwing function, like {print($0)} to “forEach”.<br class=""><br class="">— Sasha<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 20 Dec 2015, at 13:37, Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>&gt; wrote:<br class=""><br class="">Hi Alexandre,<br class=""><br class="">I think for this use case we don't actually need 'rethrows' to become<br class="">a part of the closure type, we just need the compiler to allow and<br class="">"instantiate" it in more places.<br class=""><br class="">The case where we would need 'rethrows' to become a first class part<br class="">of the type system is if we wanted 'rethrows' to be a part of the<br class="">signature of the closure itself, for example:<br class=""><br class="">(swift) let forEach = [ 10, 20, 30 ].forEach<br class="">// forEach : (@noescape (Int) throws -&gt; Void) throws -&gt; () = (Function)<br class=""><br class="">Here, a more precise type would be (@noescape (Int) throws -&gt; Void)<br class="">rethrows -&gt; Void.<br class=""><br class="">Dmitri<br class=""><br class="">-- <br class="">main(i,j){for(i=2;;i++){for(j=2;j&lt;i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>&gt;*/<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>