[swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?
jtbandes at gmail.com
Tue Feb 7 23:18:46 CST 2017
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
/// 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 <spestov at apple.com> wrote:
> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> 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?
> On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov at apple.com> wrote:
>> On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <
>> swift-dev at 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
>> and the body is always a ClosureExpr.
>> I can see one minor place
>> 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.
>> swift-dev mailing list
>> swift-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev