Skip to content

Commit 70890df

Browse files
committed
Tweak API
1 parent 437abd4 commit 70890df

File tree

1 file changed

+20
-51
lines changed

1 file changed

+20
-51
lines changed

text/2978-stack_based_vec.md

Lines changed: 20 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -86,22 +86,26 @@ Of course, fixed buffers lead to some inflexibility because unlike `Vec`, the un
8686
# Reference-level explanation
8787
[reference-level-explanation]: #reference-level-explanation
8888

89-
`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.
9090

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.
9292

9393
```rust
9494
// core::collections
9595

9696
pub struct ArrayVec<T, const N: usize> {
9797
data: MaybeUninit<[T; N]>,
98-
len: usize
98+
len: usize,
9999
}
100100

101101
impl<T, const N: usize> ArrayVec<T, N> {
102102
// Constructors
103103

104-
pub unsafe fn from_raw_parts(_ptr: *mut T, _len: usize) -> Self;
104+
#[inline]
105+
pub fn from_array(array: [T; N]) -> Self;
106+
107+
#[inline]
108+
pub fn from_array_and_len(array: [T; N], len: usize) -> Self;
105109

106110
#[inline]
107111
pub const fn new() -> Self;
@@ -140,27 +144,28 @@ impl<T, const N: usize> ArrayVec<T, N> {
140144
where
141145
R: RangeBounds<usize>;
142146

143-
pub fn extend_from_cloneable_slice(&mut self, other: &[T])
147+
pub fn extend_from_cloneable_slice(&mut self, other: &[T]) -> Result<(), &[T]>
144148
where
145-
T: Clone; // Panics at run-time
149+
T: Clone;
146150

147-
pub fn extend_from_copyable_slice(&mut self, other: &[T])
151+
pub fn extend_from_copyable_slice(&mut self, other: &[T]) -> Result<(), &[T]>
148152
where
149-
T: Copy; // Panics at run-time
153+
T: Copy;
150154

151-
pub fn insert(&mut self, idx: usize, element: T); // Panics at run-time
155+
pub fn insert(&mut self, _idx: usize, element: T) -> Result<(), T>;
152156

153157
#[inline]
154158
pub const fn is_empty(&self) -> bool;
155159

156160
#[inline]
157161
pub const fn len(&self) -> usize;
158162

159-
pub fn pop(&mut self) -> T; // Panics at run-time
163+
pub fn pop(&mut self) -> Option<T>;
160164

161-
pub fn push(&mut self, element: T); // Panics at run-time
165+
#[inline]
166+
pub fn push(&mut self, element: T) -> Result<(), T>;
162167

163-
pub fn remove(&mut self, idx: usize) -> T; // Panics at run-time
168+
pub fn remove(&mut self, idx: usize) -> Option<T>;
164169

165170
pub fn retain<F>(&mut self, f: F)
166171
where
@@ -176,49 +181,13 @@ impl<T, const N: usize> ArrayVec<T, N> {
176181

177182
pub fn split_off(&mut self, at: usize) -> Self;
178183

179-
pub fn swap_remove(&mut self, idx: usize) -> T; // Panics at run-time
184+
pub fn swap_remove(&mut self, idx: usize) -> Option<T>;
180185

181186
pub fn truncate(&mut self, len: usize);
182-
183-
pub fn try_extend_from_cloneable_slice(&mut self, other: &[T]) -> Result<(), ArrayVecError>
184-
where
185-
T: Clone;
186-
187-
pub fn try_extend_from_copyable_slice(&mut self, other: &[T]) -> Result<(), ArrayVecError>
188-
where
189-
T: Copy;
190-
191-
pub fn try_insert(&mut self, _idx: usize, element: T) -> Result<(), ArrayVecError>;
192-
193-
pub fn try_pop(&mut self) -> Result<T, ArrayVecError>;
194-
195-
pub fn try_push(&mut self, element: T) -> Result<(), ArrayVecError>;
196-
197-
pub fn try_remove(&mut self, idx: usize) -> Result<T, ArrayVecError>;
198-
199-
pub fn try_swap_remove(&mut self, idx: usize) -> Result<T, ArrayVecError>;
200-
}
201-
202-
#[derive(Debug, Eq, Ord, PartialEq, PartialOrd)]
203-
pub enum ArrayVecError {
204-
CapacityOverflow,
205-
NoElement
206-
}
207-
208-
impl fmt::Display for ArrayVecError {
209-
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
210-
let s = match *self {
211-
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-
}
216187
}
217188
```
218189

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.
222191

223192
# Drawbacks
224193
[drawbacks]: #drawbacks
@@ -229,7 +198,7 @@ New and existing users are likely to find it difficult to differentiate the purp
229198

230199
### The current ecosystem is fine
231200

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.
233202

234203
# Prior art
235204
[prior-art]: #prior-art

0 commit comments

Comments
 (0)