Currently, closures can only bind objects by reference and it is impossible to control (from user code) in which register an enclosed object should be stored. This issue proposes to change several things:
[x] add ability to control in which register the closure will store enclosed objects,
[x] add ability to enclose-by-copy,
[x] add ability to enclose-by-move,
The first point is merely an enhancement of current behaviour providing programmers more control over their programs.
Next two points are completely new features, though.
The "enclose-by-copy" behaviour would be a lightweight alternative for "enclose-by-reference"; it would only copy objects into a closure thus making them stay within the basic memory management mechanism. Enclosed object would be left intact.
The "enclose-by-move" behaviour (designed to match "pass-by-move") would be more invasive.
Enclosed object would be taken out of its native scope and put inside a closure; it would also stay within the basic memory management mechanism.
Both new enclosing methods should be more efficient than classic "enclose-by-reference" scheme.
Both should also be useful for creating functions with reduced strength, partial application and implementing lazy execution where the connection to the original enclosed object is not needed and it's the value it represented that is important. Functions like add_three(int) or log_prefixed(string) come to mind.
Currently, closures can only bind objects by reference and it is impossible to control (from user code) in which register an enclosed object should be stored. This issue proposes to change several things:
The first point is merely an enhancement of current behaviour providing programmers more control over their programs. Next two points are completely new features, though.
The "enclose-by-copy" behaviour would be a lightweight alternative for "enclose-by-reference"; it would only copy objects into a closure thus making them stay within the basic memory management mechanism. Enclosed object would be left intact.
The "enclose-by-move" behaviour (designed to match "pass-by-move") would be more invasive. Enclosed object would be taken out of its native scope and put inside a closure; it would also stay within the basic memory management mechanism.
Both new enclosing methods should be more efficient than classic "enclose-by-reference" scheme. Both should also be useful for creating functions with reduced strength, partial application and implementing lazy execution where the connection to the original enclosed object is not needed and it's the value it represented that is important. Functions like
add_three(int)
orlog_prefixed(string)
come to mind.