Stream: t-compiler/help

Topic: const fn closure


Jarod (Jul 01 2020 at 01:32, on Zulip):

Would it be reasonable in the future for rust to be able to create const fn closures? Would they close over any variables if they have static lifetimes?

eddyb (Jul 01 2020 at 03:36, on Zulip):

'static bounds are orthogonal from const fn-ness

eddyb (Jul 01 2020 at 03:36, on Zulip):

the missing thing is either a syntax, or an inference step, to determine whether the closure should be considered const fn

eddyb (Jul 01 2020 at 03:37, on Zulip):

the closed over variables are just like fields in a struct that is passed to the closure

oli (Jul 01 2020 at 05:40, on Zulip):

I'll add them to the skill tree

oli (Jul 01 2020 at 05:48, on Zulip):

done. Basically we'll need the ability to invoke trait methods, too. We already have an impl for that if the closure isn't a generic parameter but defined in the method where it is called

oli (Jul 01 2020 at 05:49, on Zulip):

so yea, I guess all that is left is to auto-force the Fn* impls for closures in const fn to be const impls

eddyb (Jul 01 2020 at 20:36, on Zulip):

@oli are you sure though? I thought I've used closures in constant contexts before, by casting them to a fn() pointer or &dyn Fn()

oli (Jul 02 2020 at 06:43, on Zulip):

yea, but you can't do it in const fn, so we can do this inside const fn

eddyb (Jul 03 2020 at 17:28, on Zulip):

I'm not too happy about the idea tbh, it feels kind of arbitrary. unless you can put runtime code in the closure and it just wouldn't be considered const Fn() but idk which parts of the compiler check that aspect of const Trait-ness

oli (Jul 04 2020 at 16:13, on Zulip):

interesting idea. I think it could be a reasonable scheme to have closures infer their constness

Last update: Sep 27 2020 at 12:30UTC