Custom closure (and trait) "kind" bounds

[bblum]

Needed to make send_mapproperly dual-mode.

The way I see it, ~fn()s should always already be Const. &fn() and @fn() could perhaps be non-const if they had &muts or @muts in their environment.

Can we check for this and support putting closures in arcs?

EDIT: Per @bstrie's request, here is a list of what how the kinds work. For each kind bound K, a closure or trait bounded like fn:K() or TraitName:K can capture any values as long as their types do not contain the following ("mq" means any mutability qualifier):

Copy        anything with a destructor, e.g. pipes, ARCs, fn:()/Trait: without Copy
'static     &'r mq T, where 'r != 'static, fn:()/Trait: without 'static
Const       &mut T, @mut T, &const T, RWARC, Cell, RcMut, fn:()/Trait: without Const
Owned       &mq T, @mq T, Rc, RcMut, fn:()/Trait: without Owned

[nikomatsakis]

I don't see why ~fn closures should be required to be const, though it is likely a good default. I have to write up the fn type proposal we discussed ... I believe it covers this use case just fine. 

Niko

(Sent from a cramped, unreliable keyboard)null

[bblum]

Oh, I mean they should be able to satisfy const requirements. Even if they have mutable data structures in their environment I think the closures themselves should still be const. Only if you can somehow change the interior of the environment, such as with @mut/&mut, should they be non-const. (I guess you can put those in fn~s just fine.)

Currently the problem is you cannot put them in ARCs at all.

[nikomatsakis]

I agree it should be possible. A closure is const if it closes over const things... this seems... straightforward enough, and akin to any of the other possible bounds on a closure's environment.

[bblum]

At a minimum. Don't you think that a closure should be const even if it closes over (owns) a mutable thing?

[nikomatsakis]

No, that would certainly not be safe to put in an ARC.

[bblum]

oh, I see. I guess I was assuming calling a closure always makes a copy of the environment.

[nikomatsakis]

(To be more explicit: because, if it is const, it could potentially be called many times in parallel, and if it mutates that closed over state, that would induce data races)

[catamorphism]

I'm closing this, reopen if you have a problem with that :-)

[bblum]

Unless the constness inference has changed since, I think there's still something to be done here. Functions that don't close over mutable data should be const, so send_map can be put into ARCs.

[catamorphism]

Nominating for maturity milestone 1, well-defined.

[graydon]

sub-bug of #2202 or #6308