View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001028 | Ecere SDK | ec | public | 2013-10-18 09:08 | 2013-10-18 09:12 |
| Reporter | darkf | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Summary | 0001028: Closure support | ||||
| Description | eC has been lacking closures support for over a decade. It's time you do something about that. Closures are just functions that inherit outer bindings, so for example: void Main() { int x = 10; int add(int y) { return x + y; } Println(add(5)); } would print out 15. Anonymous closures (lambdas) could work like so: void main() { int x = 10; PrintLn( (int y) => { return x + y; })(5) ); // call the lambda and print its result - 15 } Since closure objects may outlive their scope, they should only be defined for free variables that are immutable (constant) or reference counted on the heap. @Jerome suggested emitting a warning if the closure may outlive its scope. | ||||
| Tags | No tags attached. | ||||
| related to | 0000586 | new | Programmable function pointers on methods and as variables |
|
|
Here's a take at how this could be implemented: import "ecere" struct __ecereClosure1DataStruct { int * x; }; static int __ecereClosure1(struct __ecereClosure1DataStruct * __ecereClosure1Data, int y) { return (*__ecereClosure1Data->x) + y; } class MyApp : Application { void Main() { int x = 10; // PrintLn( ((int y) => x+y) (1337) ); { __ecereClosure1DataStruct __ecereClosure1Data = { &x }; PrintLn(__ecereClosure1(&__ecereClosure1Data, 1337)); } system("pause"); } } Normal classes with refcount would be automatically incref'ed on calls to the closure, and decref'ed at the end of the closure function. |
