Here's what I (and the majority of the community) have been going by, which I think works well:

• Named functions/lambdas are acceptable (def foo(n): n+1, foo = lambda n: n+1, int foo(int n) { return n+1; }, auto foo = [](int n){ return n+1; }).
• Unnamed functions/lambdas are acceptable (lambda n: n+1, [](int n){ return n+1; }).
• Any expression which evaluates to a (named or unnamed) function is acceptable (pow).
• Additional "helper" functions may be defined in addition to the primary solution function (f=lambda x:abs(x);lambda n:f(n)+n).
• Any imports/includes/requires/whatever may be imported/included/required/whatever outside of the function (import math;math.gcd).

In general, so long as the last evaluated expression either defines a named function or evaluates to an unnamed function, and the solution function performs consistently regardless of how many times it has been called previously, the submission is acceptable.

(note: that wording seems less than ideal, but I can't think of a way to improve it right now)

As for the code that generates all possible functions, that would be technically valid by these rules, but should be added as a standard loophole.

Here's what I (and the majority of the community) have been going by, which I think works well:

• Named functions/lambdas are acceptable (def foo(n): n+1, foo = lambda n: n+1, int foo(int n) { return n+1; }, auto foo = [](int n){ return n+1; }).
• Unnamed functions/lambdas are acceptable (lambda n: n+1, [](int n){ return n+1; }).
• Any expression which evaluates to a (named or unnamed) function is acceptable (pow).
• Additional "helper" functions may be defined in addition to the primary solution function (f=lambda x:abs(x);lambda n:f(n)+n).
• Any imports/includes/requires/whatever may be imported/included/required/whatever outside of the function (import math;math.gcd).

In general, so long as the code defines at least one function, named or unnamed, and the solution function performs consistently regardless of how many times it has been called previously, the submission is acceptable. The only exception is import-only submissions - though they bring functions into the global scope, they neither define new functions nor evaluate to a function that can be captured and/or called. Thus, from math import* is not valid, but from math import*;gcd is.

(note: that wording seems less than ideal, but I can't think of a way to improve it right now)

As for the code that generates all possible functions, that would be technically valid by these rules, but should be added as a standard loophole.

Here's what I (and the majority of the community) have been going by, which I think works well:

• Named functions/lambdas are acceptable (def foo(n): n+1, foo = lambda n: n+1, int foo(int n) { return n+1; }, auto foo = [](int n){ return n+1; }).
• Unnamed functions/lambdas are acceptable (lambda n: n+1, [](int n){ return n+1; }).
• Any expression which evaluates to a (named or unnamed) function is acceptable (pow).
• Additional "helper" functions may be defined in addition to the primary solution function (f=lambda x:abs(x);lambda n:f(n)+n).
• Any imports/includes/requires/whatever may be imported/included/required/whatever outside of the function (import math;math.gcd).

In general, so long as the last expression either defines a named function or evaluates to an unnamed function, and the solution function performs consistently regardless of how many times it has been called previously, the submission is acceptable.

(note: that wording seems less than ideal, but I can't think of a way to improve it right now)

As for the code that generates all possible functions, that would be technically valid by these rules, but should be added as a standard loophole.

Here's what I (and the majority of the community) have been going by, which I think works well:

• Named functions/lambdas are acceptable (def foo(n): n+1, foo = lambda n: n+1, int foo(int n) { return n+1; }, auto foo = [](int n){ return n+1; }).
• Unnamed functions/lambdas are acceptable (lambda n: n+1, [](int n){ return n+1; }).
• Any expression which evaluates to a (named or unnamed) function is acceptable (pow).
• Additional "helper" functions may be defined in addition to the primary solution function (f=lambda x:abs(x);lambda n:f(n)+n).
• Any imports/includes/requires/whatever may be imported/included/required/whatever outside of the function (import math;math.gcd).

In general, so long as the last evaluated expression either defines a named function or evaluates to an unnamed function, and the solution function performs consistently regardless of how many times it has been called previously, the submission is acceptable.

(note: that wording seems less than ideal, but I can't think of a way to improve it right now)

As for the code that generates all possible functions, that would be technically valid by these rules, but should be added as a standard loophole.