I had to read this 2-3 times to figure out what was going on, but I'm still not entirely sure what lead to proposing this change. I guess I'll write what I got out of it and hope I'm crazy and get corrected.
It seems to me that we're restricting what a closure can do when it executes based on the type of closure that it is. Is this in the name of safety? If so, that seems like a good idea given Rust's goals. Right now it feels like a ton of mental overhead but I'll try and play around with it and see if I have an "A-ha!" moment.
Some of the blog post, mainly the part about using a wrapper function so the compiler can still inline monomorphized functions, makes me feel like this is a bit half-baked at the moment. I mean, the very nature of closures is that they give the programmer dynamic abilities.
I really enjoy Rust and the reason I enjoy Rust is the combination of low-level programming and safety. Maybe experiments like this are what gives us that. I hope I'm just confused right now.
edit: Oh, one benefit I see already is that since these are "unboxed" there won't be an allocation.
It seems to me that we're restricting what a closure can do when it executes based on the type of closure that it is. Is this in the name of safety? If so, that seems like a good idea given Rust's goals. Right now it feels like a ton of mental overhead but I'll try and play around with it and see if I have an "A-ha!" moment.
Some of the blog post, mainly the part about using a wrapper function so the compiler can still inline monomorphized functions, makes me feel like this is a bit half-baked at the moment. I mean, the very nature of closures is that they give the programmer dynamic abilities.
I really enjoy Rust and the reason I enjoy Rust is the combination of low-level programming and safety. Maybe experiments like this are what gives us that. I hope I'm just confused right now.
edit: Oh, one benefit I see already is that since these are "unboxed" there won't be an allocation.