<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 7, 2016, at 15:08, Neil Faiman <<a href="mailto:neil.swift@faiman.org" class="">neil.swift@faiman.org</a>> 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 7, 2016, at 4:33 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">Swift very deliberately does <i class="">not</i> infer types across multiple statements in closure bodies. This is mostly an implementation restriction (our type-checking system can't handle it very well), but it's also a simple rule that <i class="">explains</i> the implementation restriction, rather than having type inference in closure bodies working some of the time but not all.</div></div></div></blockquote><br class=""></div><div class="">OK. I understand the reasoning, and agree that it makes perfect sense. Thanks for the explanation.</div><div class=""><br class=""></div><div class="">That said … I’ll note that Swift already must have logic to infer a single result type from multiple expressions, to wit, the ?: handling logic. In principle, one could collect all the return expressions in a closure and apply the same logic to them. This would have the happy consequence that common trivial cases like “only one return statement” would work as expected.</div></div></div></blockquote><br class=""></div><div>Multiple <i class="">expressions</i> and multiple <i class="">statements</i> aren't the same thing. You'd really want something like this to be inferrable too:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>let names = enumValues.map {</div><div> switch $0 {</div><div> case .Foo:</div><div> return ".Foo"</div><div> case .Bar:</div><div> return ".Bar"</div><div> case .Baz</div><div> return .Baz</div><div> }</div><div>}</div></blockquote><br class=""><div class="">…but note that I messed up in that last return statement, and now it's not clear what the return type is supposed to be. (Maybe the first two are the mistakes.)</div><div class=""><br class=""></div><div class="">(Okay, so can we collect all the <i class="">expressions?</i> No, their types may depend on previous lines, which in turn may depend on the types of the arguments, which may also not be inferrable, although in this case they are.)</div><div class=""><br class=""></div><div class="">There are certainly ways to handle more cases than what we handle today, but then we start getting into a weird territory where it's not clear what's handled and what isn't. (Arguably we're already there given how often people ask the question.) Today there's at least a simple rule: if the closure consists of a single expression (or a single return statement), the compiler will look at the body; otherwise it won't.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div></body></html>