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.
On the other hand, noticed the header comment says: /// ...Because the capture list is evaluated outside of the closure, this /// CaptureList wraps the ClosureExpr. The dynamic semantics are that evaluates /// the variable bindings from the capture list, then evaluates the /// subexpression (the closure itself) and returns the result. 🤷‍ On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spes...@apple.com> wrote: > > On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtban...@gmail.com> > wrote: > > PR'd: https://github.com/apple/swift/pull/7326 > > Although I would also ask: why is CaptureListExpr a *parent* of > ClosureExpr and not a child? > > > 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? > > Slava > > > Jacob > > On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spes...@apple.com> wrote: > >> >> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev < >> swift-dev@swift.org> wrote: >> >> 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 only one place it's built >> <https://github.com/apple/swift/blob/1e46f13184d7256c991b2ba9424af9efe3cd860f/lib/Parse/ParseExpr.cpp#L2425>, >> and the body is always a ClosureExpr. >> >> I can see one minor place >> <https://github.com/apple/swift/blob/1e46f13184d7256c991b2ba9424af9efe3cd860f/lib/AST/ASTWalker.cpp#L663-L665> >> 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*. >> >> >> Since autoclosures cannot have capture lists, I think the change you’re >> suggesting makes sense. >> >> Slava >> >> >> Jacob >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev >> >> >> > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev