Skip to content
New issue

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

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

Already on GitHub? # to your account

Consider closure autoref #21699

Closed
nikomatsakis opened this issue Jan 27, 2015 · 5 comments
Closed

Consider closure autoref #21699

nikomatsakis opened this issue Jan 27, 2015 · 5 comments
Labels
A-closures Area: Closures (`|…| { … }`)

Comments

@nikomatsakis
Copy link
Contributor

We could have a || expression expand to &F or &mut F where F : Fn() (FnMut, etc), and not just F. This would make it easier to write code that accepted boxed closures:

fn foo(x: &mut FnMut()) { ... }
foo(|| ...)

whereas today it is required to write:

foo(&mut || ...)

This seems like a pretty small delta and might go a long way towards improving ergonomic impact of the new closure design.

@nikomatsakis nikomatsakis added the A-closures Area: Closures (`|…| { … }`) label Jan 27, 2015
@nikomatsakis nikomatsakis modified the milestone: 1.0 beta Jan 27, 2015
@nikomatsakis
Copy link
Contributor Author

Nominating for beta.

@nikomatsakis
Copy link
Contributor Author

cc @aturon

@japaric
Copy link
Member

japaric commented Jan 27, 2015

(Assume that impl<F: ?Sized> FnMut for &mut F where F: FnMut is in the stdlib)

If you have a function fn foo<F: FnMut>(_: F) and you call foo(|| { .. }), would the compiler prefer to pass the unboxed closure by value? Because it could pass either F or &mut F (or even &mut FnMut) in this case, right?

@nikomatsakis
Copy link
Contributor Author

Closing in favor of rust-lang/rfcs#756

@nikomatsakis
Copy link
Contributor Author

@japaric I'll answer your question over in the RFC

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-closures Area: Closures (`|…| { … }`)
Projects
None yet
Development

No branches or pull requests

2 participants