You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`ArrayVec` is a contiguous memory block where elements can be collected, threfore, a collection by definition and even though `core::collections` doesn't exist, it is the most natural module placement.
89
+
`ArrayVec` is a contiguous memory block where elements can be collected, therefore, a collection by definition and even though `core::collections` doesn't exist, it is the most natural module placement.
90
90
91
-
The API basically mimics most of the current `Vec` surface with some tweaks and additional methods to manage capacity. Notably, these additional methods are fallible versions of some well-known functions like `insert` that will return `Result` instead of panicking at run-time.
91
+
The API basically mimics most of the current `Vec` surface with some tweaks to manage capacity. Notably, these additional methods are fallible versions of some well-known functions like `push` that will return `Result` instead of panicking at run-time.
Self::CapacityOverflow=>"It is not possible to add more elements",
212
-
Self::NoElement=>"There are no elements in the vector",
213
-
};
214
-
write!(f, "{}", s)
215
-
}
216
187
}
217
188
```
218
189
219
-
Meaningless, unstable and deprecated methods like `reserve` or `drain_filter` weren't considered and in general, everything that includes or removes elements have a fallible version: `extend_from_cloneable_slice`, `extend_from_copyable_slice`, `pop`, `remove` and `swap_remove`.
220
-
221
-
A concrete implementation is available at https://github.com/c410-f3r/stack-based-vec.
190
+
Meaningless, unstable and deprecated methods like `reserve` or `drain_filter` weren't considered. A concrete implementation is available at https://github.com/c410-f3r/stack-based-vec.
222
191
223
192
# Drawbacks
224
193
[drawbacks]: #drawbacks
@@ -229,7 +198,7 @@ New and existing users are likely to find it difficult to differentiate the purp
229
198
230
199
### The current ecosystem is fine
231
200
232
-
Even with all the fragmentation, different types of memory usage is an overkill in certain situations. If someone wants to use stack memory in an embedded application, then it is just a matter of grabbing an appropriated crate.
201
+
`ArrayVec` might be an overkill in certain situations. If someone wants to use stack memory in a specific application, then it is just a matter of grabbing the appropriated crate.
0 commit comments