I have a struct member vector that might be presented and might not. The obvious choice is to put it behind Option.
But if I do that, when I'll set the option to None, I'll free the vector. The next time it will have to be re-allocated.
This is bad. I want to re-use the capacity from the previous time.
I can build a container that does that, but is there a built-in way to do this?
You can use Option::take() to get the old value of the vector and store it somewhere for reuse, and Vec::clear() to empty the vector without reducing its capacity.
How do you plan on using the Vector?
Exactly like the previous time; I process input and in some parts of it I need access to the vector.
I can also store the vector without Option and also store a boolean indicating whether the vector is accessible; However, I don't want to manually deal with storing/restoring the vector.
Have you considered having a different type for each state your algorithm can be in that only has the fields valid in that state?
Well, that’s the global allocator’s job; if you don’t like how it behaves, you either need to implement the alternative manually or find a crate that does.
This doesn't work this way. I don't have other data accessible for each state (then I could define an enum), but instead data that is always available and data that's available based on certain conditions (that may overlap).
I don't understand what you say, I replied to your idea:
And said that using this way I'll have to manually store the vector in a different field and keep track on where it's available.
@nologik, That's exactly why I said I can implement it myself but looking for a built-in way 
My point was that, aside from exceptional situations, giving the vector’s memory back to the allocator when you’re not using it and allocating a new one when you need it again is performant enough.
If your situation is one of the exceptional ones, it’s unreasonable to expect to not write at least some memory-management code specific to your use case. And writing a thin wrapper around a 2-field struct isn’t that much effort in the grand scheme of things.
Got it