The description says:

"Your memory tape should be large enough - the original implementation had 30,000 cells but a few thousand should suffice for this Kata"
and:
"The memory pointer should initially point to a cell in the tape with a sufficient number (e.g. a few thousand or more) of cells to its right."

However in C# at least, no test case requires more than 15 memory cells. Even if using the same memory tape for all tests without ever clearing it or winding it back, only 24 cells are needed. If this is intentional, the description's references to requiring thousands of cells should probably be changed

',' means to copy the next unused byte from the input string to the data cell at the data pointer. '+' means to increment the value of the current data cell.

The input is separate from the "data" which acts as temporary memory.

While this would have been better posted as a suggestion, I agree that the description could be clearer for people who don't already know how it's supposed to work.

Execution times out for me.

Interestingly this is ~5x slower (run by CodeWars at least) than Garcian1991's almost identical solution, just substituting ElementAtOrDefault for ToArray.

Brilliant!

Weirdly both worked for me. Did someone edit it?

imho the wording of the description is unfair. I suggest changing to:

"You have to return an int Array filled with numbers from 0 to 3999999

The numbers have to be in ascending order.

But there is a problem. You have to do this very very very very quick."

It might be worth making some mention of compiler choice in the description. My solution fails on Mono (it defaulted to Mono for me), but completes in less than half of the required time under .NET 8.0.

Iteresingly this seems to run very significantly faster on Mono, via this site at the time of writing at least.

"Write a function called that takes..."

Possible typo?

Yeah, when reading the description I was planning a bunch of stuff. Wrote the first section to narrow down the possibilities and realised I didn't need anything else.

In C#, many of the top solutions are initialising a variable for comparison using default(T), but will fail if an input begins with default(T). This includes a list (not a string) of numbers beginning with 0 for example.

Tests should be added or altered to include collectins of numbers beginning with 0 (rather than just 1 as in the current list tests).