Approved.

Maybe a little bit similar... But this was the condition I was asked about during the technical interview, so I decided to add it. It is a bit similar in terms of the condition, but the logic of returning the result and finding it is slightly different

Added 100 random tests

Expanded the description with clearer examples

Specified in description two cases where the function returns -1: insufficient funds and exceeding the available days of vacation compared to rental days

Enhanced basic examples

Fixed issues causing false positive test results in certain programming languages (e.g., JavaScript)

Added logging of input data (m, k, cost) in case of test failure for better debugging

Also, invalid input is not specified to return -1. Insufficient availability is different from insufficient funds; it should be specified separately.

( eleven languages while in Beta ?!? )

Resolved in this fork

Fixed in Python

updated to F# 6.0 + NUnit, using tuples

added some time ago

funny how 4 others did it as well

Nice to hear, thank you!

I will write a usual review. the original translator is still around so I won't hijack the translation yet.

I can, later today or tomorrow.
The solution setup looks good, so if you approve and problems are found, tests could be improved without invalidating solutions.
After skimming briefly over the code of tests I did notice one or two WTFs, but nothing what couldn't be fixed after approval.

Thanks, I fixed the first issue, and I also attempted to patch up the fstring loop-hole. Let me know your feeback!

What's wrong with "eval"? While you have to deal with other problems except calculating strings as values, I think using "eval" is defntely okay.

Evaluation at runtime of values provided by user is hardly ever a good idea, for many reasons, but main of them being security: it will wreak havoc if user solution returns something like "system(wipe_hdd)" or "apt_get install mymalware" etc. That's why eval should not accept user input, and when it does, the input must be properly sanitized. Except it's difficult, and users can obfuscate input in ways which pass sanity checks and still execute malicious code (for example a JSFu*k expression, or similarly obfuscated). Even if eval can be sometimes used safely with user input, it's difficult and it's just better not to.
Calling eval with your own input, which is not derived in any way from user input, might be not that bad, but it's usually unnecessary: if it's you who builds the input, you usually already know how to evaluate it.
There are also secondary reasons like performance, poor user experience, etc. but vulnerability to user-crafted malicious inputs is one of the main factors.