[swift-dev] Why doesn't CaptureListExpr hold a ClosureExpr?

[Jacob Bandes-Storch]

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 <spestov at apple.com> wrote:

>
> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes at 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 <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
>> <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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170207/36af221a/attachment.html>