I understand that xs.len() is said to be >=3 and Rust has some underflow protection.
Yet still xs.len() - 1 is a buggy programing practice I don't that makes me nervous.

Really clean.

I've finally read that I had to round results, but test cases for C++ showing me:

ExampleTests
Expected: [ 4.2, -35.8, -2.8, 23.2, 11.2 ]
Actual: [ 4.2, -35.8, -2.8, 23.2, 11.2 ]
were really misleading.
They were literaly telling me that x is not the answer because the answer is x.

One could tinker with TC_COUNT and RANGE constants in “Test Cases” section.
Interesting configurations include:

• TC_COUNT = 0, RANGE = 0..=1000 which would enforce 0 randomness and covering literally all cases that abide by specification.

_ is NOT unreachable. It can be reached due to misuse of the provided function.
This match arm should panic with clear message targeting API user who misused the function.

Looks preety, concise, speedy, and... unreadable anyway.

For me hard to read so I mark as Clever not Best Practice, but this is subjective opinion.

I like the simplicity.

BUT this is hardly reliable implementation.

It shouldn't be upvoted as best practices.

Test it against:

assert_eq!( two_sum(&[i32::MAX, 1, i32::MIN, 0], i32::MIN), (2, 3));

Or do simple load test like:

    use rand::{prelude::*};
    let mut rng = thread_rng(); const LOAD: usize= 1_000_000;
    let loaded: Vec<_>= std::iter::repeat_with(|| (rng.next_u32()%1_000) as i32).take(LOAD).chain([1234, 5678, 9012]).collect();
    do_test(&loaded, 14_690);

Testcases are weak, but again this solution is not best practices it can give false results in unexpected moments or just deadlock for large input.

I reported issue with incomplete testcases.

Because there's no TC with zero on the right in Rust version
(eg. assert_eq!(solve(&[16,17,14,3,14,5,2,0]),[ 17,14,5,2,0]);),
wrong solutions do pass and are upvoted.