Prevent regions from being closed over and hidden from view

[nikomatsakis]

Because a &T type is copyable, it is currently possible to close over them using an fn@() (and, eventually, iface@). This is clearly wrong. We need a new kind---perhaps heap or gc?---indicating data which is not only copyable but also copyable into a shared closure. This goes in between copy/send, I think.

[graydon]

Shared or unique, same problem.

I don't think this is a kinding problem, I think it's a region problem. You should not be able to write a region pointer into any region other than one of its own subregions. Forming a heap closure is such a write, and should be prohibited just as forming a heap record full of stack region pointers would be.

[nikomatsakis]

A heap record is totally allowed.

[nikomatsakis]

To clarify, it is legal to do this:

let x = 3;
let f = @{g: &x};

that poses no particular problem. I could see it being useful if you have a long-running computation with some context that is passed by region ptr, but the internal data used by the computation might be garbage-collected.

Naturally all of those heap-allocated records will not be accessible after the computation finishes.

[graydon]

Wow, I totally thought (and think) that should not be legal. We'll have to discuss once I'm at an irc window :)

[nikomatsakis]

this is done for closures in commit 0e42004

[pnkfelix]

related to #5723

[Aatch]

I think that has been fixed by the work @bblum did on trait and closure bounds.

Closing, re-open if I'm wrong.

[bblum]

I didn't solve region-related issues; we still lack the capability to write ~Trait:'a or somesuch. @nikomatsakis can confirm.

[catamorphism]

Marked as clarifying - @nikomatsakis will investigate.

[pcwalton]

Nominating because I believe this is fixed.

[pnkfelix]

@nikomatsakis still needs to investigate, he is not certain it is fixed, and if it isn't, it still is on plate for 1.0

[aturon]

Nominating. I believe this issue has been resolved with #16453

[pnkfelix]

closing as fixed