-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Support canonicalized closures #1652
Comments
This comment was originally written by @seaneagan Also, method closurization should be idempotent. This falls under the category of the second paragraph above since |
Added Area-Language, Triaged labels. |
Issue #2402 has been merged into this issue. |
Added this to the M1 milestone. |
Somewhat related to 144. |
see also http://code.google.com/p/dart/issues/detail?id=3060 and http://code.google.com/p/dart/issues/detail?id=144. All these should be considered and resolved in a cohesive fashion. |
Static methods and top level functions are compile-time constants starting with the 0.10 draft. However, we have not taken any such decision on arbitrary functions. Removed Type-Defect label. |
This issue was originally filed by @seaneagan
If a closure only captures scope names which are compile-time-constant, then it itself is compile-time-constant, and thus should always evaluate to the same exact closure object. This should be relatively easy to implement, since it can be accomplished by the compiler itself.
If a closure captures the same non-compile-time-constant variables on multiple evaluations, then each such evaluation could produce the same closure object. This would presumably require storing a table to map between captured variables, and the resulting closures. Thus, this might be a bit more difficult to implement, at least in JavaScript.
The text was updated successfully, but these errors were encountered: