1. Description should be more clear about all the operations your solution should support. For example, the JS tests expect curried chains to be able to accept other chains, such as in add(1)(add(2)(3)). This makes sense, but it is not asserted in all languages, and since it's not made explicit, many solvers wouldn't factor it into their API design for statically typed languages (like C++).
2. For a class of valid solutions, the C++ version runs into a quirk with Snowhouse as was pointed out by many comments below. Snowhouse will try to check whether it can stringize your class, triggering compilation errors in some cases, forcing you to have to overload operator<<, despite printability being irrelevant to the task requirements. Assertions will need to be done in a way that gets around this quirk. I'd have done it myself, but I would much prefer that the kata requirements are fully formalized first (issue #1).

Great problem! Learned a lot.

Suggestion (for Python): The tests can fail with the following unhelpful results:

1 should equal 1
3 should equal 3
6 should equal 6

What's happening here is that one of the 1's is an integer and the other is a string. It would be nice if the tests detected this and pointed it out.

Kotlin translation

I get an igglo crash dump when I try to do an object that implements the () operator -> works on my side with a C++17 compiler

Hello guys! Can u help me? How can I make this function return final result? Is it possible?

def add(n):
    def another(x):
        nonlocal n
        n += x
        return add(n)
    return another

Could someone reference me to the python resources I would need to learn to tackle this problem?

no random tests in:

• TypeScript
• ruby