> On Feb 7, 2017, at 9:30 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
>
> Thanks to the magic of git blame:
>
>
> https://github.com/apple/swift/commit/f3ed7e93e142b802171bfe0dd08b88aa0d8b320b
>
> <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 Tue, Feb 7, 2017 at 9:27 PM, John McCall <rjmcc...@apple.com
> <mailto:rjmcc...@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 <spes...@apple.com
>> <mailto:spes...@apple.com>> wrote:
>>
>>> On Feb 7, 2017, at 9:09 PM, Jacob Bandes-Storch <jtban...@gmail.com
>>> <mailto:jtban...@gmail.com>> wrote:
>>>
>>> PR'd: https://github.com/apple/swift/pull/7326
>>> <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
>>> <mailto:spes...@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
>>>> <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
>> <https://lists.swift.org/mailman/listinfo/swift-dev>
>
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
