For Swift, there is a example test XCTAssertEqual(boolfuck(";"), String(bytes: [0x01], encoding: .isoLatin1)!). The code only outputs the bit in the default position, and yet the test says it should be 1. In the next test, printing Hello, world!\n, the code for the first part is ;;;+;+;;+;+;, which is 00010010. This clearly shows that the default data bits in the cell are 0, so the first test should print the character with value 0 not the character with value 0x01.

Damn. CodeWars needs to do something about these broken tests. Makes me so frustrated I want to stop coming here.

Test cases for Swift need to be more robust.

There is no specification about the shift parameter, and the only restriction is that it should be an Int type. If such is the case, test cases should check for cases where the shift is > 26, < 0, and check whether it is still working fine. Either that or the description/API should reflect this.

Also, some solutions for Swift will break if the input were to be encode("zzzz", 2) which is a valid input

Okay. I found the reason. Remove all \rs (carriage return) from the test cases and they should work fine. Someone please fix this.

Test for Swift prints Process exited prematurely with a SIGILL signal. in the log, even when the code just returns an empty string.

Damn!! This was reported 6 months ago!! Someone, please.

Given the description of the kata, it seems the list itself should be reversed; therefore, the test cases should actually test whether the original list was reversed. But the kata test case checks only for the data equality, and not the object equality. This can be an issue if there is a reference to a list somewhere else. I would like to make changes to the Swift test cases if this is what you agree with.

Also, I want to suggest making two variants of the reversing function: reverse(_:) and reversed(_:). In the Swift language, whenever the function name is in the past participle, e.g. sorted, the function returns new instances. Hence, sort sorts the array the function is called on whereas sorted() returns a new sorted array instance.

The caesar cipher part was fun. The runner part sapped all fun from the kata. Seems very contrived and unnecessary/arbitrary. I appreciate you posting a lot of katas, but a kata should be made difficult because the problem itself is difficult; not because the problem is not explained well or has another unrelated subproblem tagged onto another problem.

I wonder if there is a good algorithm for computing available paths. Also, I think it would be nice to have the paths converted to String instances, so we can know that people aren't cheating with hard-coded, precomputed numbers.

The kata is very fun, but the interface of the given function is poor. Since Swift is strongly typed, the interface should make use of that instead of allowing users to pass a nil as the argument.

The sample test cases are still not working. You can pass the kata though.

It seems to be fixed now. However, on one occasion, the test reverted to the wrong version. Thank you.

The test case for 8.2M ohms evaluates to gray brown green gold. I believe it's gray red green gold? The language is Swift.

People will press clever for anything that looks remotely like a one-liner... :(