Kattis 'Driver's Dilemma'
Design
I applaud the goal of using struct and impl, but this is a good example of where object-oriented style can go wrong: it is not clear exactly what functionality Car and MPG encapsulate. Rather, these are just structs that carry some relevant data for the in_range function, but they do not seem to lead to a meaningful &quot;separation of concerns&quot; or make the code easier to understand as written.
For example, what is an MPG object? It carries a pair of a miles-per-hour and a miles-per-gallon, but why are these particular pieces of data grouped together and not with the other pieces of data? For Car, the primary problem is that it carries a lot of data but not enough functionality. If I were to reuse or extend your code, I would not be sure what to use a Car for, and whether and how I should extend Car with additional methods.
To improve your code, I would start by getting rid of MPG. Then, I would settle on a simple abstraction of a car that seems generalizable. We could start with this: a car is something that drives, given a certain amount of fuel, a fuel leak rate, a certain speed, and a certain fuel efficiency. Note that we no longer have efficiancy: Vec&lt;MPG&gt; as part of the car --- that muddles the meaning of a car, since it can then only drive at certain rates.
We might get something like the following design:
struct Car {
    fuel_remaining: f32, // Gallons
    fuel_leak_rate: f32, // Gallons/hour
    speed: f32, // Miles/hour
    efficiency: f32, // Miles/gallon
}
impl Car {
    fn new(
        fuel_remaining: f32,
        fuel_leak_rate: f32,
        speed: f32,
        efficiency: f32,
    ) -&gt; Self {
        assert!(fuel_remaining &gt;= 0);
        assert!(fuel_leak_rate &gt;= 0);
        assert!(speed &gt; 0);
        assert!(efficiency &gt; 0);
        Self { fuel_remaining, fuel_leak_rate, speed, efficiency }
    }
    fn can_drive(&amp;self, distance: f32) -&gt; bool {
        let time = distance / self.speed;
        let fuel_req = time * self.fuel_leak_rate + distance / self.efficiency;
        fuel_req &lt; self.fuel_remaining
    }
}

What I want to stress here is that the design is extensible:

First, we've articulated the requirements on our struct in the new function: which arguments must be greater than or equal to zero, possibly equal to zero, and so on.

Second, we've simplified the functionality to can_drive which just checks whether we can drive a given distance, but we could now imagine adding other functions, like fn drive(&amp;mut self, distance: f32) to actually do the drive, fn out_of_gas(&amp;self) -&gt; bool to check if we are out of gas, fn fill_up(&amp;mut self, new_gas: f32), and so on. These additional features would conceptually align with what the object is designed for.


A Note On Units
Although overkill for this example, another improvement to your design would be to make use of Rust's type system to keep different units separate at compile time. Here's how you would do that: first we define struct wrappers for each different kind of unit we are interested in:
struct Miles(f32):
struct Gallons(f32):
struct Hours(f32);
struct MPH(f32);
struct MPG(f32);

Then we can define operations like multiplication for the particular types which &quot;make sense&quot; to multiply. E.g.:
use std::ops::{Add, Mul};

impl Add for Hours {
    type Output = Self;
    fn add(self, other: Self) -&gt; Self {
        self.0 + other.0
    }
}
impl Mul&lt;Hours&gt; for MPH {
    type Output = Miles;
    fn mul(self, time: Hours) -&gt; Miles {
        self.0 * time.0
    }
}

and so on.
The beauty of this approach is that we get a compiler error if we make any arithmetic mistakes, like adding Miles to Hours. And moreover, that comes for free: in the actual running code, Miles and Hours both compile to plain f32 values.
Minutae
In addition to what the other answer said, run cargo clippy! It usually gives very helpful suggestions. Here you can replace remaining: remaining with remaining.  It would also be great to see some unit tests.