Open nadako opened 4 years ago
This seems pretty narrow... one problem (among possibly others) is that this might cause locals to become captured, like future
in your case.
I've made a demo commit to a branch to show that this is theoretically quite easy to do in the dataflow optimization. It doesn't work for your actual example due to the local capturing situation. If that can be figured out, maybe this optimization is worth it.
Feel free to check a diff to see if this actually does anything for you. In the unit tests I'm seeing a couple instances where this kicks in.
Well that doesn't change anything in my current codebase, but that's mostly because we're just starting to use closures in general and building blocks like the Future as well. I made this issue because I've noticed something that could be generated better when I was introducing Future in the codebase and checked the generated code. :) I'm curious if that has more effect for the haxetink people :)
I'll check again after migrating our codebase to tink_core ^^
I didn't quite understood the part about "local capturing situation" though, I guess that's something we should experiment with while diffing outputs for real-world code?
It rejects the transformation with the when not (is_special_var v)
guard. This is to avoid pushing non-captured locals into closures and thus turning them into captured ones, which isn't working because the filter which handles capturing has already run at this point.
Suppose we have this code:
this will currently generate:
which is technically correct, however it's not the best performane-wise, because we don't really need the
$bind
here. Ideally, we would tempvar the object and "propagate" method call, i.e.:(not tempvaring
future
here as it's already a local)