Maybe should've lead with that last part..

I updated the description, and I gave up on managing other people's translations a long time ago.

No. My complaint is that your description leads the programmer in error, as the specification is lacking. I'm just calling it out, because it brings in accidental complexity to the question. I don't see anything wrong with using Unicode. It's the same as ASCII if you use std::wstring.

I'd also check the test cases for Cpp, as your signature is expecting ASCII strings as a return type. Having people manually manage multi-byte characters is not only unnecessary, given the standard already supports Unicode, but would also rocket the difficulty way past 4kyu, given the amount of corner cases one has to handle. It would be a Kata in and off its own.

As for encodings being ciphers, I get your analogy, but it lacks precision. Encodings exist to store information efficiently. Ciphers exist to obfuscate information. It's akin to saying cats are dogs..

Thanks for the update, I'm sure it'll save a lot of people a lot of time.

Also, clarified utf-8 in the kata description.

Unicode I/O is a fundamental, and this kata is intended to be a step up from fundamentals. A bigger problem is that the Vigenere Autokey Cipher Kata is assigned a lower rank than this one.

Also, could get into a separate argument that ciphers are encodings. That's not really the true heart of your complaint, which would be that Unicode is hard in C++. The original Python version of this kata was very hard because Python wasn't always so intuitive with Unicode, and then Codewars wouldn't let you edit the solution after it was approved.

Right. Still, this is an exercise about ciphers, not an exercise about encodings. If your cipher functions in ASCII it'll also function in UTF-8. If your test cases require changing locale and using special-case strings in a given language, the problem description should indicate so. Otherwise you're just creating accidental complexity.

It's only the most commonly deployed electronic data format in the world.

Makes utterly no sense to test the kata on UTF-8 encodings without mentioning that beforehand. While kiddy languages like Python and JS handle it nicely, those of us doing it in C++ will be forced to jump through hoops only to handle character conversion. Not to mention that UTF-8 encodings have utterly nothing to do with the question at hand

Perhaps next time structure your test cases better. Cheers

Gotta love floating points.

twoDecimalPlaces(1.005);

• will turn 1 and we expect 1.01

Thank you both! I was able to fix it with these tips :D

Look at the example, your code needs to extend the key as needed. You've added the failsafe to encode, but not to decode method.

Why am I getting this error?

Traceback (most recent call last):
File "/workspace/default/.venv/lib/python3.11/site-packages/codewars_test/test_framework.py", line 112, in wrapper
func()
File "/workspace/default/tests.py", line 19, in it1
test.assert_equals(c.decode("xt'k o vwixl qzswej!"), "it's a shift cipher!")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/workspace/default/solution.py", line 29, in decode
new_index = alphabet.index(text[i]) - alphabet.index(key[i])
~~~^^^
IndexError: string index out of range

Shouldn't the key be the same length as the text to encode, meaning that if text[i] exists then key[i] exists? I added a failsafe while loop:

while len(text) < len(key):
key = key + key

and still get the error. Thanks for any suggestions!

How am I supposed to handle multi-byte katakana, especially given that test cases are called with key="" alphabet=""?

And the fixes have been merged, thanks tor letting me know!