Typo

Author: c410-f3r

text/2978-stack_based_vec.md

@@ -86,7 +86,7 @@ Of course, fixed buffers lead to some inflexibility because unlike `Vec`, the un
 # Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
-`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 modulo placement.
+`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.
 
 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.
 
@@ -190,13 +190,13 @@ impl<T, const N: usize> ArrayVec<T, N> {
 
     pub fn try_insert(&mut self, _idx: usize, element: T) -> Result<(), ArrayVecError>;
 
-    pub fn try_pop(&mut self) -> Result<(), ArrayVecError>;
+    pub fn try_pop(&mut self) -> Result<T, ArrayVecError>;
 
     pub fn try_push(&mut self, element: T) -> Result<(), ArrayVecError>;
 
-    pub fn try_remove(&mut self, idx: usize) -> Result<(), ArrayVecError>;
+    pub fn try_remove(&mut self, idx: usize) -> Result<T, ArrayVecError>;
 
-    pub fn try_swap_remove(&mut self, idx: usize) -> Result<(), ArrayVecError>;
+    pub fn try_swap_remove(&mut self, idx: usize) -> Result<T, ArrayVecError>;
 }
 
 #[derive(Debug, Eq, Ord, PartialEq, PartialOrd)]