No. return is sufficient. :)

This is how it would be implemented in every PHP codebase I've seen, haha :)

Apparently, tests are too weak in this kata, haha :)

Same here. And I have been writing JS for more than half a decade now..
Thanks! :)

Haha, I loved the creative use of in operator. And bit shift added that magical touch to it. (Although not correct) :D

This one is crazy! :)

Love this one! :)

Great solution! :)

Love me some bonus points ;)
Great kata thanks. :)

Thought about this already. I will update the description. Thank you. :)

@JohanWiltink
Thank you for your feedback. :)

"Every kata should be a Best Practice kata. Otherwise you'll be teaching people bad habits ( and I consider inconsistent data types a bad habit )"
This is very valid point, which actually made me think harder on this problem.

"...it would seem simpler to just return the input in cases where it can't be numeronymed. Problem with returning inconsistent data types is you can't trust the return value; you'll always have to do some additional processing on them."
Just returning an input, "Garbage in -> Garbage out" style, causes essentially the same problem, meaning "you can't trust the return value; you'll always have to do some additional processing on them.”, to make sure the procedure did what was expected. So this is not a solution, in my opinion, and can be actually harder to debug, than returning different data type. Correctness over everything.

"...( which is why I prefer strong typing anyway )"
Me too, but this is somewhat irrelevant, and we have to work with what is on the table.

I'm voting for throwing an exception because:
a) Exceptions are JavaScript's native mechanism for dealing with cases like this one.
b) It's more "fail fast", meaning it’s more noticeable, and you can also spot throw keyword in the implementation somewhat easier than returning different data types.
c) Output of the procedure is always correct.

Someone could argue, that throwing an exception, could be thought of as returning different data type, but both return and throw have different semantics, and I think throw is more appropriate in this case.

I will wait for your opinion, and then, if you agree, I would like to refactor this kata to require throwing (let's say a RangeError).

Thank you :)

@FArekkusu

Marking this as resolved, as I promised.

As mentioned previously, this is not a "best practice" kata.
In my eyes, this might be suggestion at best, not an issue.
You didn't provide any constructive feedback, or backed your argument.

Thank you.

Marking as resolved.

Random tests implemented.