View Issue Details

IDProjectCategoryView StatusLast Update
0001028Ecere SDKecpublic2013-10-18 09:12
Reporterdarkf Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Summary0001028: Closure support
DescriptioneC 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.
TagsNo tags attached.

Relationships

related to 0000586 new Programmable function pointers on methods and as variables 

Activities

jerome

2013-10-18 09:12

administrator   ~0001134

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.

Issue History

Date Modified Username Field Change
2013-10-18 09:08 darkf New Issue
2013-10-18 09:12 jerome Note Added: 0001134
2014-05-19 20:16 jerome Relationship added related to 0000586