Author approve the Rust translation, please!

Big thank you for your note! Indeed, arithmetic overflow is what I should keep in mind when I do multiplication. I rewrote my solution - replaced multiplication with division and modulo operations. Seems working for extremal cases.

TypeScript solution is not compiled even with a trivial body ('return 0').

Thank you! Your answer deserves to be in the description.

Can anybody exlain the example, how did we get 1100... from dots and dashes?

Why do you use drain(..) instead of into_iter() if you do not use the vec digits later? Why don't you use from_digit().into_iter() instead of from_digit().unwrap().to_ascii_uppercase()?

Description:

where all numbers are positive ints.

Rust code:

i64

Should be:

u64

OMG! 4 members (the 1st is 0) are enought.

I was thinking: "or this kata is trivial, or I am stupid to understand the task".
I guess the kata has complexity of 7 kyu.

A better fn signature for the Rust translation:
fn decomp(n: u64) -> String
Why? Because the domain of the factorial is non negative integers.

A better fn signature for the Rust translation:
fn consec_kprimes(k: usize, arr: Vec<u64>) -> u64
Why? Because we deal with positive integer numbers.

The descriptions is incomplete and contradictory.
The dot . is a non-alpha-numeric symbol, but it does not clutter a line, it is a part of an address (according to the tests).
The underscore _ not just adds more garbage, but replaces a single space (according to the tests).
It would be good to mention these corner cases.

The description is talking about positive integers. Why is the type of numbers i64 (in Rust code), not u64?