This is marked as resolved, but still seems to be a problem for the sample test cases.

Fair play, that is more elegant. As a question, why allow negative prices or servings?

The lambda function is being bound to the variable test_password, effectively making it a named function. ethan_ is code golfing for fun, which is when you try to complete a challenge with as few characters as possible. Maintainability isn't the goal.

I applied minimal changes to remove the warnings that appear in stderr, as well as updating the description for Rust to use the correct terms field and struct. Code style could also be improved but I didn't want to editorialize.

Ah, we've gone full circle now.

It doesn't seem to be bad at all. There are always nitpicks like an unecessary .to_string() before parsing and type hint that would have been inferred, but it looks like pretty standard Rust code.

Though I do wonder, if you wanted to write a Perl solution, why not fork it in that language directly?

Just so you know, the purpose of .expect("text goes here") is to provide context if the unwrap panics. If you don't feel the need to provide context, a simple .unwrap() makes more sense.

I've been wondering, do you think random tests are helpful in kumites? It looks like asserting the equality of two implementations, which only works when the reference is known to be definitely correct (in which case, why not use it in the first place instead of doing testing?).

Or maybe you're writing them just for practice, I don't know.

It's a good implementation, but by nature converting a number into a string is much more complicated than a simple while loop which runs a dozen or so times.

Because sentinal values are a bad idea for many reasons, though you probably already learned this in the 4 years since.

However I'm still bamboozeled as to why it returns Option<Vec<i32>> as opposed to Option<[i32; 3]>. This isn't an arbitrary list, it's exactly 3 elements. I might even expect Option<(i32, i32, i32).

Mind clarifying? Rust implicitly returns the last expression in a function body if that's what you were wondering.

lol. I've checked on godbolt and we've been getting less and less efficient (at least in terms of assembly length). My initial solution was 186 lines, then 247, and yours is 504. It's not an actual speed comparison, but assuming it's a similar effect, that would show an inverse relation to legibility.

Yours is definitely the most legible, whereas my initial minimizes the number of passes.

Is there a reason usize is not used for the return type? It seems more natural if we're going to do conversions anyways, since a negative value is meaningless. Plus now there are situations where we can't give the correct answer. [i16::MIN, i16::MAX] would product an answer of 2^16 - 2, which is way to big to fit in an i16. I guess if we're going for minmalism u16 would be the appropriate type, but would require more conversion unless the input was also &[u16].

I understand that take, but not from a JavaScript developer. I'm intrigued. What do you think makes it worse than JavaScript?

Hmm, the descritions looked identical, but in the editor there was some weird old/===/yours formatting that I removed in the new fork. They should be identical behind the scenes too now.