<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 Jun 29, 2016, at 11:03 PM, boris via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; font-size: 14px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; min-height: 18px;" class=""><font face="Menlo" class="">//Report Error: Ambiguous reference to member ‘map’ </font></div><div class=""><font face="Menlo" class="">// </font></div><div style="margin: 0px; font-size: 14px; line-height: normal; color: rgb(79, 129, 135);" class=""><font face="Menlo" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">numbers</span><span style="font-variant-ligatures: no-common-ligatures;" class="">.map({</span></font></div><div style="margin: 0px; font-size: 14px; line-height: normal;" class=""><font face="Menlo" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> (number: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">) </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">in</span></font></div><div style="margin: 0px; font-size: 14px; line-height: normal;" class=""><font face="Menlo" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> v</span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">ar</span><span style="font-variant-ligatures: no-common-ligatures" class=""> ret = </span><span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">3</span><span style="font-variant-ligatures: no-common-ligatures" class=""> * number</span></font></div><div style="margin: 0px; font-size: 14px; line-height: normal;" class=""><font face="Menlo" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">return</span><span style="font-variant-ligatures: no-common-ligatures" class=""> ret</span></font></div><div style="margin: 0px; font-size: 14px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><font face="Menlo" class="">})</font></span></div></div></div></blockquote><br class=""></div><div>I asked the same question a few months ago; the answer was that it is a deliberate design choice that you can only omit the return type from a single-expression closure (and that the error message is less than helpful). For example, Jordan Rose offered this explanation:</div><div><br class=""></div><div><div class=""></div><blockquote type="cite" 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 class=""><br class=""></div><div class="">As Chris pointed out, the compiler could definitely do a better job communicating the problem, but actually <i class="">changing the behavior</i> here would require significant implementation work. So this is not considered a "bug", just an implementation-driven design choice.</div></blockquote><div class=""><br class=""></div></div>Regards,<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Neil Faiman</div></body></html>