tickets should return a string like "YES" or "NO", not booleans.
Please upgrade to Swift 5.

This one should be the best. If the list gets much longer, it still calculate the result pretty fast!

It's in Javascript as well and it is rather annoying - you have to read the comments to find out that even though tests testify a working encoder code it is your encoder code you have to fix to pass the random DECODING tests.
Would be a nice kata otherwise, but with that test setup it's a pain in the ass for all bit shifters....

The fixed one has a call to round on line 87 of the test cases, but for some reason the one I see when I click Show Test Cases is still the old non-fixed one. Do you know if you could check to see if you know how to get the fixed one used? Otherwise, I could try resubmitting it.

People are reporting errors with the Swift translation again, can you look into that? Here is a link:
https://www.codewars.com/kata/resistor-color-codes-part-2/discuss#5a6b4ced880385af58000183

I wasn't sure if I should require a lazy solution like the haskell one so I did

If you don't think this is a good idea, I can remove the requirement

Thanks.

I'm working on it. At this point I've got an array of required letters with corresponding prefixes and sorted it by length of its elements. It's pretty hard to implement sorting in ascending order, didn't figure it out yet. PS. Finally passed all the tests - my solition looks pretty ugly though :). An awesome kata despite its description was a little bit vague to me at first.

I think the description of the sorting should explicitly say that the sorting happens on the entire string with the 1/2/E/= prefix, not just the repeated letters. The current wording doesn't specify this and can easily be interpreted as just applying to the repeated letters.

Looks good, though personally I would have preferred leaving the argument labels in (since it's very hard to tell what's what in areaOfPolygonInsideCircle(3, 3), but it's obvious in areaOfPolygonInsideCircle(radius: 3, sides: 3)), but changing that now would break existing solutions so oh well.

Swift infers the types of literals based on what you're using them in. This means that you don't need 2.0 (just use 2), and you don't need Double(1000) (just use 1000).

It happens in Ruby at least

Which language?

Thanks for the translation!

I don't program in Swift, but saw you passed the original kata, and took the effort to adapt it to Swift, including the random testcases and all. I haven't checked the code carefully but still, I trust you did a good a job so I'm approving it.
Thanks for the translation, btw.