@nikomatsakis Submitted a WIP #54802. It does what we want (roughly) with the test case but it is affecting other errors and I'm not sure it's better for those.
@davidtwco cool :)
@nikomatsakis are you happy with
returns a reference to a captured variable which escapes the closure body and
returns a closure that contains a reference to a captured variable, therefore escaping the closure body as the error messages for the non-closure and closure case respectively?
I don't love "therefore" :)
it doesn't seem like the correct conjunction..
.."thereby" maybe but that's a bit over the top
"which then escapes the closure body"?
it's ambiguous then what is escaping
although in fact it doesn't matter
so maybe that's fine
let's go with that for now :)
@nikomatsakis Pushed that.
Hey @davidtwco I just made a quick note on something you may have overlooked in @nikomatsakis 's feeddback
personally I'd be fine with r+'ing PR #54802 as is
but if you think you'd be able to quickly incorporate the distinction between "inner closure" and "outer closure" when two closures are in play, then I'm happy to wait for that before r+'ing.
Otherwise, I can just r+ and we can refine it further after it lands...
(its also possible that the "inner closure" and "outer closure" distinction is actually unnecessary given the way that things are being phrased in the PR as is, which may be why i'm so inclined to r+ it as is...) :smile:
I think the current wording was intended to resolve the inner/outer closure comments.
But I’m not sure if there was any feedback on that wording.
If you think we could or should make an inner/outer distinction more clear in the wording then I’m happy to do so.
@nikomatsakis @pnkfelix if either of you could come up with wording that is preferred for this then I'll update the PR as soon as so we can get it landed :slight_smile:
no I think its fine