no need to check if numbers are repeated, just check for membership in the subset

I got it. Thank you so much!

Oh ok nevermind what I said then, I thought it had some special meaning. C does have enumerated types (enums), and it would be perfectly reasonable to have enum outcome { LOSE = false, WIN = true}; here

I don't know TS either ( I know JS, but it doesn't have the enum type ).

But I think they're effectively the same ( up to implementation details ).

he should rather look up the comma and parenthesis operators. JavaScript does not have tuples :p

Not a kata issue.

You're failing because your code is incorrect. Look up includes on MDN.

sorry for being a bit dumb : what's the difference between an enum and an Enumerable ? I know you dont know C, but let's take as example a TypeScript enum, which are syntactically identical to C ones

I am very much used to Boolean being an Enumerable in Haskell; the concept fits perfectly ( and coerce = toEnum . fromEnum works perfectly for custom Enumerables that are isomorphic to Booleans ).

But if that's not a thing in C, maybe we should not be blaming a 7kyu kata for not using this useful abstraction in a language that doesn't have it ( even if it could be retrofitted quite nicely ).

bool is not implemented as an enum bool { false, true }; if that's what you mean by enumerable. the C standard does not mention the word enumerable

Sloppy code, or optimised code?

"Enumerable" would mean they have enum values I guess ( just quoting Dinglemouse here - is this not a well-defined concept in C? ). It would mean some conversion ( or coercion ) to and from ( unsigned, bounded? ) integers is possible.

in C bool is an integer type that can only hold two values, 0 and 1. true and false are just macros that expand to 1 and 0, respectively. NULL pointers and integral-type zeroes are falsy, everything else is truthy (this includes 0.0, sadly).
bool is not implemented as an enum bool { false, true }; if that's what you mean by enumerable

also, I agree that WIN being truthy and LOSE falsy would make sense, but I did not do it for the reason that I said, it might allow sloppy code to take advantage of memory that happens to be zeroed

LOSE / WIN are isomorphic to booleans FALSE / TRUE ( and it could be argued that the return value should actually have been a boolean ). Are booleans enumerable? ( I don't know C. ) If so, it would not seem unreasonable to give LOSE / WIN the same values as FALSE / TRUE.

the problem is that 0 is a value that's going to appear in memory in a lot of places, and this can result in sloppy code that passes the tests (code that forgets to initialize stuff or to return values for example). So I try to prevent that with enum values above 0. In this specific example there would be an use case for things likeif (WIN) { doStuff }, but most of the time you are not supposed to care about the actual values of enum members, it breaks abstraction.