<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="">Hi Ross,<div class=""><br class=""></div><div class="">That's a good point. Do you mind filing a JIRA issue for this?</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 11:56 AM, Ross LeBeau <<a href="mailto:ross.lebeau@gmail.com" class="">ross.lebeau@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class="">Hi Slava,</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class="">Thanks for the insight. This is what I suspected, but I wasn't sure about how set the team was on this concept. Currently, it seems that if the types cannot be inferred, the type checker picks an implementation and checks against that.</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class="">E.g., the following code works because it conforms to the signature of the flatMap that the type checker decided to use:</div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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; margin: 0px;" class=""><div id="bloop_customfont" style="margin: 0px;" class="">b = a.flatMap { elem in</div><div id="bloop_customfont" style="margin: 0px;" class=""> print(elem)</div><div id="bloop_customfont" style="margin: 0px;" class=""> return 1</div><div id="bloop_customfont" style="margin: 0px;" class="">}</div><div id="bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="margin: 0px;" class="">Given that adding multi-statement type inference is off the table, perhaps you could consider adding a helpful message when this situation arises? Like if type inference of a closure fails, and the closure doesn't type check with the assumed context, maybe tell the user "Did not infer types, try explicitly declaring them"?</div><div id="bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="margin: 0px;" class="">Just trying to think of a way to guide a less advanced user, since this error could arise from many functions and also from genuine errors, so it may be hard to google/ask for help with.</div></div><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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=""><div id="bloop_sign_1468002824529006080" class="bloop_sign" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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;"><div style="font-family: helvetica, arial; font-size: 13px;" class="">-- <br class="">Ross LeBeau<br class=""></div></div><br style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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=""><p class="airmail_on" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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;">On July 8, 2016 at 2:31:46 PM, Slava Pestov (<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>) wrote:</p><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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;"><span class=""><div class=""><div class=""></div><div class="">Hi Ross,<span class="Apple-converted-space"> </span><br class=""><br class="">Swift's type inference operates at the level of a single statement. This is why we can infer parameter and return types for single-expression closures. While conceptually, it would not be a huge change to the type checker algorithm to support global type inference for closures and other functions consisting of multiple statements, we feel that philosophically, this is not a direction the language should take. Global type inference will further exacerbate performance problems with type checking, as well as make it harder to produce good diagnostics.<span class="Apple-converted-space"> </span><br class=""><br class="">So really, this has less to do with closures per se, and more with just the general design and philosophy of the type checker.<span class="Apple-converted-space"> </span><br class=""><br class="">(Please correct me if I've mis-represented anything here -- this is my recollection of listening in on various discussions in the past).<span class="Apple-converted-space"> </span><br class=""><br class="">> On Jul 8, 2016, at 10:00 AM, Ross LeBeau via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> It seems that the compiler fails to infer the type of an anonymous function if the function contains more than one statement. For example, this works:<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> let a = [[1,2],[3],[4,5,6]]<span class="Apple-converted-space"> </span><br class="">> var b: [Int]<span class="Apple-converted-space"> </span><br class="">> b = a.flatMap { elem in<span class="Apple-converted-space"> </span><br class="">> return elem<span class="Apple-converted-space"> </span><br class="">> }<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> But this fails with an error "cannot convert return expression of type '[Int]' to return type 'Int?'":<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> b = a.flatMap { elem in<span class="Apple-converted-space"> </span><br class="">> print(elem)<span class="Apple-converted-space"> </span><br class="">> return elem<span class="Apple-converted-space"> </span><br class="">> }<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> And, of course, if you explicitly type the function, it works again:<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> b = a.flatMap { (elem: [Int]) -> [Int] in<span class="Apple-converted-space"> </span><br class="">> print(elem)<span class="Apple-converted-space"> </span><br class="">> return elem<span class="Apple-converted-space"> </span><br class="">> }<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> Greg Titus informed me that this is due to a heuristic in the compiler where it only imports the outer context when type-checking anonymous functions with a single statement. Before we knew this, I and others, found it perplexing that out of two functions that return the same value, one will compile and the other will not.<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> Are there any plans to extend the context of type-checking in the case of a failure like this? If not, is it something to consider? It seems like a difficult problem to solve without rather advanced knowledge of what's going on.<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> Also if this has already been brought up, forgive me, I just subscribed to this list and a quick search of the archives didn't get any hits :)<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> --<span class="Apple-converted-space"> </span><span class="Apple-converted-space"> </span><br class="">> Ross<span class="Apple-converted-space"> </span><br class="">> _______________________________________________<span class="Apple-converted-space"> </span><br class="">> swift-dev mailing list<span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><span class="Apple-converted-space"> </span><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a></div></div></span></blockquote></div></blockquote></div><br class=""></div></body></html>