Tracking issue for RFC 1558: Allow coercing non-capturing closures to function pointers

[aturon]

RFC

Summary:

A closure that does not move, borrow, or otherwise access (capture) local variables should be coercable to a function pointer (fn).

Outstanding issues:

• expected types of closure arguments are not inferred when coercing to a fn #41755 -- inference shortcomings
• ICE when coercing certain closures (with discarded arguments) to fn #40204 -- ICE

[est31]

I'd like to implement this. Which steps are required?

[aturon]

@est31 Awesome, thank you!

@eddyb or @nikomatsakis, can one of you give some pointers?

[eddyb]

I'd reuse the existing "reify to fn pointer" coercion (see the code that applies it).
The difference for a TyClosure is you have to check that tcx.with_freevars gives you an empty vector.

Then HIR+Ty->HAIR lowering of the reify coercion has to generate something like... wait, no 😢
So this is the "hard part":
I want to suggest <closure as FnOnce(...)>::call_once as fn(...) -> _ which would work at the lowest level, because we ignore that first argument, but it doesn't type-check (the MIR, that is).
So you'd have to keep around a reify coercion, and only in trans get a FnOnce::call_once DefId and pass the closure and the tupled arguments as type parameters (in a Substs).
But with those you should be able to use Callee::def(ccx, def_id, substs).reify(ccx) to get the fn pointer.

[est31]

Hmm seems its more than I thought. As I'm rather tight with time this week, is it a problem if I implement it only next week?

[aturon]

@est31 Absolutely! I don't know of anyone chomping at the bit to do this implementation work.

[nikomatsakis]

@eddyb I am not so sure how I feel about using this coercion. In particular, as we discussed in the RFC thread itself, it would imply that the closure from which we coerce is a "zero-capture" closure -- well, I guess we can actually check that eagerly easily enough, since the list of upvars that a closure uses is something we analyze very early. (i.e., the freevars list is available quite early.)

[eddyb]

@nikomatsakis I've assumed we use that early check all along ;).

[nikomatsakis]

@eddyb well as usual you're two steps ahead of me. =) Have pity on an old man.

That said, do we want to allow said coercion is you only capture zero-sized types? I guess I'm happy not to permit that for now. =)