Why doesn't CaptureListExpr hold a ClosureExpr?


(Jacob Bandes-Storch) #1

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*.

Jacob


(Slava Pestov) #2

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

···

On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org> wrote:

Jacob
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Jacob Bandes-Storch) #3

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?

Jacob

···

On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@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


(Slava Pestov) #4

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

···

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

Jacob

On Tue, Feb 7, 2017 at 7:56 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(Jacob Bandes-Storch) #5

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.

/// ...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 the other hand, noticed the header comment says:

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@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@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


(Slava Pestov) #6

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.

Unless you think there’s something to be gained, I’m not sure it’s worth it…

/// ...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.

This makes sense, but as I understand it, evaluating the closure itself has no side-effects so this is irrelevant.

Slava

···

On Feb 7, 2017, at 9:18 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
On the other hand, noticed the header comment says:

🤷‍

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@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@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(John McCall) #7

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.

/// ...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.

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.

John.

···

On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org> wrote:
On the other hand, noticed the header comment says:

🤷‍

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@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@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto: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 <mailto: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


#8

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.

/// ...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.

If so, why function body is NOT a child of, so to say, ParamListExpr?

That said, inverting the relationship means that every ClosureExpr has the
pointer to the capture list. Maybe we can use TrailingObjects for that, but
I'm not sure it's worth it.

···

2017-02-08 14:18 GMT+09:00 Jacob Bandes-Storch via swift-dev < swift-dev@swift.org>:

On the other hand, noticed the header comment says:

🤷‍

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@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@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


(Jacob Bandes-Storch) #9

Thanks to the magic of git blame:

https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b

Unless you think there’s something to be gained, I’m not sure it’s worth

it…

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 rdar://19146761 was?)

···

On Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmccall@apple.com> wrote:

On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev < > swift-dev@swift.org> wrote:
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.

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.

John.

🤷‍

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@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@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


(Slava Pestov) #10

Thanks to the magic of git blame:

  https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b

> Unless you think there’s something to be gained, I’m not sure it’s worth it…

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 rdar://19146761 was?)

"This crashes the compiler, we’re not setting up declcontext’s right:

func f(a : () -> ()) {}

class C {
  var i = 42

  func g() {
    f({ [myI = {i}] in () })
  }
}"

···

On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

On Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
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.

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.

John.

🤷‍

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@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@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(John McCall) #11

Thanks to the magic of git blame:

  https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b

> Unless you think there’s something to be gained, I’m not sure it’s worth it…

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 rdar://19146761 <rdar://19146761> was?)

"This crashes the compiler, we’re not setting up declcontext’s right:

func f(a : () -> ()) {}

class C {
  var i = 42

  func g() {
    f({ [myI = {i}] in () })
  }
}"

Well that certainly doesn't seem like a good enough reason to complicate the expression.

...are we really emitting this as a let-binding in the outer function that we just capture normally? Er, alright, I guess it works.

John.

···

On Feb 8, 2017, at 12:33 AM, Slava Pestov <spestov@apple.com> wrote:

On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

On Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Feb 8, 2017, at 12:18 AM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
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.

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.

John.

🤷‍

On Tue, Feb 7, 2017 at 9:10 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@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@apple.com <mailto:spestov@apple.com>> wrote:

On Feb 7, 2017, at 7:30 PM, Jacob Bandes-Storch via swift-dev <swift-dev@swift.org <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev