-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare 0.4, more vec-like api and error reform #61
Conversation
- Add try_insert / try_remove to be the old fallible variants that return errors - Insert that pushes out if full does no longer exist -- full vec is an error
This means odds is no longer a public dependency, which simplifies the version story for arrayvec
Also use pub(crate), requiring Rust 1.18
Required rust version should be in rustdoc Reason: Written in one or a few places. Information is versioned with the crate on docs.rs
Use same signatures (meaning: panics on errors). Add fallible versions .try_push() and .try_push_str()
I'd prefer methods that panic on invalid indices and return an error on capacity error. Maybe we could also ask other developers about this. I think the proposed fallible allocation API on internals.rust-lang.org also behaves that way. |
Thanks for the feedback. Even if this crate is moving at glacial pace. From my #55 (comment)
|
I'd be interested in taking care of this crate. What do you think? |
Sure. We can do it together? I'm not sure what you have in mind. In one way we want to guide this crate towards 1.0, but we're missing a few pieces from Rust for that (ManuallyDrop in Rust 1.20 and uninit data in inline field clarification is ??). With API overhaul it feels like we are ready with every we can do on our side. (Clearly integer generics is not something to wait for 1.0 for) |
Yes, of course together. I would like to discuss the error returning some more (this defnitely won't a roadblocker for contributing either way). I'd also like to finally introduce |
Sure, that sounds good! I had some discussion on #rust-libs and they sort of brought me over to mixing panic and result for insert. If we think of arrayvec as a Vec with a particular inline allocator, we have the problem of fallible allocation (capacity is limited); and a hypothetical fallible allocation It's not obvious that fallbility of insert is just about allocation/capacity, but with the comparison to Vec it seems ideal to make it that way. And thus another reminder that arrayvec is obsolete once custom allocators get so far that Vec can be backed by an array! That sounds cool. |
Sigh, I don't know anymore if it's best to have the error cases in push or in the separate fallible version. Both those seem fine |
I'd prefer the non-prefixed ones, but that's no strong opinion. Do you want to finish this API change yourself or should I do it? |
I can finish it |
try_insert has a capacity error, but panics if the index is out of bounds.
We turn these into "checked" removals, similar to `.pop()`. Name swap_pop seems straightforward and nice, remove_opt is not as certain.
ping @tbu- if you want. This is getting better with the feedback IMO. Most of your thoughts have been incorporated. PR description updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing this functions that just do function().unwrap()
makes me a bit uneasy, but I guess it's ok.
All in all, it looks good to me.
panic!(concat!("ArrayVec::", $method_name, ": index {} is out of bounds in vector of length {}"), | ||
$index, $len) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the standard library, this is in a separate method to remove code size from the hot code path (where the array indices usually aren't out of bounds).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. The approach is to more or less go for correct with this PR and safe fast for later. I'm not sure we can find a difference, but it would be nice to at least put the panic formatting code in a place that is independent of the type parameters.
src/lib.rs
Outdated
/// The `index` must be strictly less than the length of the vector. | ||
/// | ||
/// ***Panics*** if the `index` is out of bounds. | ||
/// vector. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra word.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Yes -- the unwraps have room for improvement. They should all be Result::unwrap's so they have their error information there in a basic form. |
Let's go, so that we finally clear this hurdle. |
New rust version requirement is open to suggestions... Right now I can't imagine that the current era Rust versions are going to break like Rust 1.0 - 1.10 ish seem to have done, but maybe I'll be surprised. |
push, insert
etcWith the goal of making arrayvec more of a "drop-in" for Vec, we realign the signatures methods
.push(elt), .insert(index, elt)
and.remove(index)
.try_push
etcMimicing something like fallible allocation, we have the fallible new methods:
Notice that
try_insert
still panics ifindex
is out of bounds.pop_at
etcMimicing
.pop()
, we have new “checked” versions ofremove, swap_remove
:The rationale is: indexing out of bounds is not a regular runtime error, it's normally a contract violation. So when we introduce checked versions of such API, then we get “checked” versions that return
Option
. Non-presence is not necessarily an error.ArrayString::push
etcCloses #46
Closes #45
Miscellaneous Changes