Conversation
|
Looks to be in the right direction, that's nice - I'll be a bit unreachable during the summer, but back in a bit |
|
Ok great, ArrayVecImpl has made it possible to share some core code. Any other ideas for how to share more? This is quite a lot of code to duplicate, even of probably half of it is necessary. |
|
|
||
| impl<T: Copy, const CAP: usize> ExactSizeIterator for IntoIter<T, CAP> { } | ||
|
|
||
| impl<T: Copy, const CAP: usize> Drop for IntoIter<T, CAP> { |
There was a problem hiding this comment.
This iterator doesn't need to implement Drop - because T is Copy.
| } | ||
|
|
||
| /// A draining iterator for `ArrayVecCopy`. | ||
| pub struct Drain<'a, T: Copy + 'a, const CAP: usize> { |
There was a problem hiding this comment.
Drain could be a candidate for sharing between the two implementations, even if it requires a bit of refactoring.
| pub use crate::arrayvec::{ArrayVec, IntoIter, Drain}; | ||
|
|
||
| #[cfg(feature="copy")] | ||
| pub use crate::arrayvec_copy::ArrayVecCopy; |
There was a problem hiding this comment.
There are other public items inside arrayvec_copy that we need to make reachable for the users - for example its iterator types. It's likely it needs to be in its own module, what do you think?
There was a problem hiding this comment.
Yes, its own module would make using it easier.
| /// The caller must ensure the length of the input fits in the capacity. | ||
| pub(crate) unsafe fn extend_from_iter<I, const CHECK: bool>(&mut self, iterable: I) | ||
| where I: IntoIterator<Item = T> | ||
| { |
There was a problem hiding this comment.
Maybe this method can move to the ArrayVecImpl trait?
|
Nice to see you are back. I will do the changes to make it better. This was more of a quick workaround for those needing this badly... I'll think of some ways to minimize code duplication too. |
|
Doing this with a macro would be the easiest way to remove loads of code duplication. Is that something you think would be acceptable for this crate? (Some people don't like macros 😅) |
|
Hi. Please use rebase and not merge to update the PR. Sorry I've been away from github a lot. Macros are ok, I like them, also wrote some eyesore ones myself. Now it's hard to judge in every case, but let's say that we want method bodies to be easy to read. I wouldn't put a whole module's worth of code through 1 macro, maybe it can be per method (or group of smaller trait impls). |
|
I am not sure what I did to my repo I am going to start over. |
|
Don't worry. I think you could have force-pushed to your PR branch if you wanted. Doesn't matter so much now. |
|
I would love to see this functionality in arrayvec. @pYtoner what was left to finish with this? |
|
I had other stuff to do so I forgot about this @jacobsvante. :/ But I'll look into whats changed in the crate since then. Maybe this is a lot easier to implement now. |
|
So the crate is pretty much the same as when I tried to do this PR. The problem was that I had skill issues with git.. Not sure if this crate is still maintained though but I'll fix my PR. |
|
That sounds lovely! Let me know if you need some help with Git (though I'm not exactly a master myself!) |
|
@bluss Are you still maintaining this repo? |
|
@jacobsvante Alright I opened a new one: #261 |
|
Thanks @pYtoner 😀 |
3 participants
Made a copy of ArrayVec (ArrayVecCopy) that can only hold Copy items.
This means copying all of its relevant functions and relevant tests.
Closes #32