Not a kata suggestion

Thanks, my bad. You rock.

You can? You are just missing __eq__ so the comparisons do not work

Why can't I use OOP (in Python) and make a class called Add() and use call() and repr()???
It perfectly satisfies the requirements with a factory function def Add() and is 100% legal.
Ridiculous.

I think this racked up upvotes from people misreading the error. This exact error just means your solution probably supports ... == some int but not some int == .... So this isn't a kata issue; you have to be able to accomodate equality in both directions.

Now the other common issue with error: use of overloaded operator '<<' is ambiguous; that's a kata issue and has been flagged multiple times above.

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).

This would have been a very good chance for testing oop and callable object.

huh ??

Cool kata!
It took me a lot of thinking, and some reading and trial and error before I managed to make it work.

You're misreading the two tests and assuming that they're the same but expecting two different results. They're not the same, hence the different expectations.

If you don't yet see it, try replacing the call operators with add operators and add newlines after the semicolons - thus presenting it in a more familiar format and also forcing you to read it as part of editing it.

I don'tknow about C++ tests, but at least in javascript:

it("Must be able to store values", () => {
		const a = add(1)(2);
		const b = add(3)(4);
		equal(a, 3);
		equal(b, 7);
	});

There is no a(3) call there.

Do these tests contradict each other?
must_be_able_to_store_curried_functions
auto a = add(1)(2); a(3) == 6
Expected: equal to 6
Actual: 3
//////
must_be_able_to_store_values
auto a = add(1)(2); a(3); a == 3
auto b = add(3)(4); b == 7
Test Passed

yes, with closure

@brodiemark, that error message is both accurate and fair. You defined a repr that is indistinguishable from int and then your complaint is that your repr is indistinguishable from int. It's also explicitly stated in repr's docs that you shouldn't do that.

Okay, I see. Thank you.