GOAT!!!

Could you explain?

oh my dear lord... you must be doing taxes. \m/

Wow, this is a lot of work. Interesting solution :D

There is no reason why the input string could not include duplicate characters.

Approved in fork!

Also, edited the assertion messages to become more readable~~

You need to update to the latest version (1.60).

I really appreciate the effort of this kind of educative katas, especially for a language like Rust (lifetimes give me frequently headaches), but, with the new version of this kata (I mean the function's signature that has been amended) I have tried something out intuitively and it worked immediately, I don't feel like I learnt anything (yesterday I was unable to solve it, though reading the documentation...). Maybe it would be nice to have something more elaborated but with more step by step / documented instructions? Just an idea...

Well, some workarounds are still possible, but they require managing lifetimes at least to some extend, so I guess it may be OK...

@Unnamed all of the solutions you've submitted do not pass anymore; please, check whether the issue can be resolved now.

Thank you. Wonderful suggestions. I like the second idea more.

That's an improvement, although I'm not sure whether I really like the fix. IMO, it'd be better if ys had a lifetime of &'b instead of an undeclared &'c, so that the task is focused solely on resolving the lifetimes problem rather than have an additional step of fixing a typo (only to arrive at the following code anyway):

fn merge<'a, 'b>(xs: &'a Vec<usize>, ys: &'b Vec<usize>) -> Vec<&'a usize> {
    xs.iter().chain(ys).collect()
}

Perhaps you could change the initial solution to make the user debug an incorrect attempt at fixing the lifetimes instead, which I think would be more interesting:

fn merge<'a, 'b, 'c: 'a + 'b>(xs: &'a Vec<usize>, ys: &'b Vec<usize>) -> Vec<&'c usize> {
    xs.iter().chain(ys).collect()
}

but that's up to you, whichever thing you choose, the original issue is okay resolve as is.

you can't make a meaningful kata if the compiler is giving away the exact code that you have to type in to make it work.

You are right.

I changed the signature, so the compiler does not show the solution, but helps to figure it out. And more; if you use the compiler it suggests the wrong fix at first.

But i found this one: https://www.codewars.com/kata/50654ddff44f800200000004. Is this not relevant to your issue? The compiler says, what you can do to fix.

In that case, Rust is simply not the right language for this type of bugfixing problems - you can't make a meaningful kata if the compiler is giving away the exact code that you have to type in to make it work.