Hey! Yeah, closures complicate this. I left another response on reddit too just now, but TL;DR:

My plan for closures is: When we’re doing phase 3 for a function and we encounter a closure, we gather all the group information of the arguments that we’re feeding to the closure, temporarily suspend borrow checking of the caller, and go do the full phase 3 on the closure, supplying it the parent’s group information, and ultimately calculating the mut effects of the closure.

That’s the only way to do it that I can see, so far. Luckily, it doesn’t add any more phases, it’s really just suspending one borrow check for another.

score 1 · canonical

Hah, nicely done =) refresh the page!

score 1 · canonical

An (IMO) neat new application of an existing technique. Hope you all enjoy =)

score 2 · canonical

deleted by creator

deleted by creator

Yep, that’s exactly right, well said.

score 1 · canonical

Thanks =) Another thing that will help with path abstraction is “associated groups/paths”, which are like associated types but for groups/paths.

I think invalidation will work well with concurrency. The more I implement it, the more I’m discovering that invalidation and normal borrow checking are actually kind of the same thing (the difference between them lies elsewhere). So I think it’ll deal with concurrency the same way as normal borrow checking. Specifically:

• If someone has a reference into some data that is currently being shared to another thread via structured concurrency, they won’t be able to mutate it during the structured concurrency.
• If someone has a reference into some data that has been moved to another thread, they won’t be able to dereference it because, well, it’s been moved away.

I’m having trouble putting it all in english, but I feel like a key here is that if a function (or scope?) has no mut effects, then it’s effectively taking an “immutable” reference. From that, all the normal shared-xor-mutable benefits apply.

score 1 · canonical