<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 Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks to the magic of git blame:<div class=""><br class=""></div><div class=""> <a href="https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b" class="">https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b</a><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">> <span style="font-size:12.8px" class="">Unless you think there’s something to be gained, I’m not sure it’s worth it…</span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">I was going for idiot-proof-ness of the AST types. I'd never heard of CaptureListExpr before and would've just assumed it was part of ClosureExpr. But it looks like the change was pretty intentional. (Maybe someone can share what <a href="rdar://19146761" class="">rdar://19146761</a> was?)</span></div></div></div></blockquote><div><br class=""></div><div>"This crashes the compiler, we’re not setting up declcontext’s right:</div><div><div><br class=""></div><div>func f(a : () -> ()) {}</div><div><br class=""></div><div>class C {</div><div> var i = 42</div><div><br class=""></div><div> func g() {</div><div> f({ [myI = {i}] in () })</div><div> }</div><div>}"</div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><br class=""></div></div></div></div><div class="gmail_quote">On Tue, Feb 7, 2017 at 9:27 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="">I don't think it would be a very big parser change to invert the relationship. Maybe I'll try it out and put up another PR.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">On the other hand, noticed the header comment says:</div><div class=""><br class=""></div><div class=""><div class="">/// ...Because the capture list is evaluated outside of the closure, this</div><div class="">/// CaptureList wraps the ClosureExpr. The dynamic semantics are that evaluates</div><div class="">/// the variable bindings from the capture list, then evaluates the</div><div class="">/// subexpression (the closure itself) and returns the result.</div></div></div></div></blockquote><div class=""><br class=""></div></span>I think the original representation just made the captures part of the ClosureExpr, and IIRC Chris changed it to this intentionally. I don't remember why; maybe it was causing problems for some tooling that wanted to walk the expression tree and find uses of the variable? It's certainly kindof weird for IRGen.</div><span class="gmail-HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">John.</div></font></span><span class="gmail-"><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">🤷<br class=""></div><div class="gmail_extra">
<br class=""><div class="gmail_quote">On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <span dir="ltr" class=""><<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class="gmail-m_-7540441854893191245gmail-"><blockquote type="cite" class=""><div class="">On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank" class="">jtbandes@gmail.com</a>> wrote:</div><br class="gmail-m_-7540441854893191245gmail-m_-7115685859560707654Apple-interchange-newline"><div class=""><div dir="ltr" class="">PR'd: <a href="https://github.com/apple/swift/pull/7326" target="_blank" class="">https://github.com/apple/swif<wbr class="">t/pull/7326</a><div class=""><br class=""></div><div class="">Although I would also ask: why is CaptureListExpr a <b class="">parent</b> of ClosureExpr and not a child?</div></div></div></blockquote><div class=""><br class=""></div></span>I think it’s kind of arbitrary. You could also argue that they should be one and the same AST node. I think right now it’s just a property of how the parser works, the capture list comes first, before the closure body?</div><span class="gmail-m_-7540441854893191245gmail-HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Slava</div></font></span><span class="gmail-m_-7540441854893191245gmail-"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail-m_-7540441854893191245gmail-m_-7115685859560707654gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <span dir="ltr" class=""><<a href="mailto:spestov@apple.com" target="_blank" class="">spestov@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class="gmail-m_-7540441854893191245gmail-m_-7115685859560707654m_-1882571583119174456Apple-interchange-newline"><div class=""><div dir="ltr" class="">I just learned about CaptureListExpr when working on some diagnostics. Is there a particular reason that its member "closureBody" is an Expr* and not a ClosureExpr*? There seems to be <a href="https://github.com/apple/swift/blob/1e46f13184d7256c991b2ba9424af9efe3cd860f/lib/Parse/ParseExpr.cpp#L2425" target="_blank" class="">only one place it's built</a>, and the body is always a ClosureExpr.<div class=""><br class=""></div><div class="">I can see <a href="https://github.com/apple/swift/blob/1e46f13184d7256c991b2ba9424af9efe3cd860f/lib/AST/ASTWalker.cpp#L663-L665" target="_blank" class="">one minor place</a> where it might be less convenient to have a ClosureExpr, but otherwise there doesn't seem to be much of a reason to keep it generalized to Expr*.</div></div></div></blockquote><div class=""><br class=""></div></span>Since autoclosures cannot have capture lists, I think the change you’re suggesting makes sense.</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br clear="all" class=""><div class=""><div class="gmail-m_-7540441854893191245gmail-m_-7115685859560707654m_-1882571583119174456gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
</div></div></div>
______________________________<wbr class="">_________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></span></div></blockquote></div><br class=""></div></div></div>
______________________________<wbr class="">_________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""></span></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>