New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom closure (and trait) "kind" bounds #3569

Closed
bblum opened this Issue Sep 24, 2012 · 17 comments

Comments

Projects
None yet
5 participants
@bblum
Contributor

bblum commented Sep 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Sep 24, 2012

Contributor

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

Contributor

nikomatsakis commented Sep 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Sep 24, 2012

Contributor

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.

Contributor

bblum commented Sep 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Sep 24, 2012

Contributor

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.

Contributor

nikomatsakis commented Sep 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Sep 24, 2012

Contributor

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

Contributor

bblum commented Sep 24, 2012

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

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Sep 24, 2012

Contributor

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

Contributor

nikomatsakis commented Sep 24, 2012

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

@bblum

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Sep 24, 2012

Contributor

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

Contributor

bblum commented Sep 24, 2012

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

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Sep 24, 2012

Contributor

(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)

Contributor

nikomatsakis commented Sep 24, 2012

(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

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Dec 28, 2012

Contributor

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

Contributor

catamorphism commented Dec 28, 2012

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

@bblum

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Dec 28, 2012

Contributor

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.

Contributor

bblum commented Dec 28, 2012

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.

@bblum bblum reopened this Dec 28, 2012

@catamorphism

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Apr 29, 2013

Contributor

Nominating for maturity milestone 1, well-defined.

Contributor

catamorphism commented Apr 29, 2013

Nominating for maturity milestone 1, well-defined.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon May 9, 2013

Contributor

sub-bug of #2202 or #6308

Contributor

graydon commented May 9, 2013

sub-bug of #2202 or #6308

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis May 9, 2013

Contributor

Repurposing this issue to be the issue that represents the needs to allow closures to have custom bounds.

Contributor

nikomatsakis commented May 9, 2013

Repurposing this issue to be the issue that represents the needs to allow closures to have custom bounds.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon May 9, 2013

Contributor

accepted for well-defined milestone

Contributor

graydon commented May 9, 2013

accepted for well-defined milestone

@bblum

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Jun 8, 2013

Contributor

I think we should have these on traits, too. It would be nice to be able to store heterogeneous existentials inside of an ARC.

Contributor

bblum commented Jun 8, 2013

I think we should have these on traits, too. It would be nice to be able to store heterogeneous existentials inside of an ARC.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 8, 2013

Contributor

Yes this is the plan.

Contributor

nikomatsakis commented Jun 8, 2013

Yes this is the plan.

bblum added a commit to bblum/rust that referenced this issue Jun 23, 2013

@bblum

This comment has been minimized.

Show comment
Hide comment
@bblum

bblum Jul 16, 2013

Contributor

This is pretty much done, except for clone, which would be harder. Opening a separate issue for that.

Contributor

bblum commented Jul 16, 2013

This is pretty much done, except for clone, which would be harder. Opening a separate issue for that.

@bblum bblum closed this Jul 16, 2013

@nickdesaulniers

This comment has been minimized.

Show comment
Hide comment
@nickdesaulniers

nickdesaulniers Jan 17, 2014

As a heads up, not sure if this comment was ever resolved.

nickdesaulniers commented Jan 17, 2014

As a heads up, not sure if this comment was ever resolved.

@bblum bblum removed their assignment Jun 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment