Change:
Currently, has a  method which takes a parameter so that if the resize involves growing the vector, the parameter is cloned into each newly-created cell in the vector. must implement in order for this method to be available. It would be useful to add a method that instead requires that , and calls to fill the newly-created cells. Not only would this be ergonomic, but for certain implementations of , it might allow the compiler to make better optimizations.
This would be an interesting addition for types which support but not . I'll try and make a PR for it. In the future, just FYI, feature requests should go in the RFCs repository.
Ah OK, noted. That's even for feature requests like this one that don't deserve an RFC?
Yep! The general rule is either PR here or RFC elsewhere. Also, would you mind renaming this issue to "Tracking issue for Vec::resize_default" ? And would you mind tagging it?
Gotcha; thanks!
Nominating for stabilization. The only potential concern is that we can generalize this to take a closure (see below). I don't know that it'd be all that useful, though, so I'm inclined to say that we shouldn't do so, and and are the two "producing" traits in std, so standardizing around them seems logical.
I'd be willing to make a PR that adds under a separate feature flag. I think that all three are useful; would simply be documented as equivalent to
I might lean more towards just having , for now at least. It's strictly more powerful and doesn't seem all that more verbose than ?
My concern is that hampers discoverability - you have to come across and then connect the dots to realize that you can do . Especially for beginners (and people who are ctrl+f-ing through the docs), this will probably make it less likely for people to figure out that they can resize using the default value.
Discoverability is pretty easily fixed by just having some documentation, though, right? I like the power of , but I'm wondering about optimizability. Especially for types (I guess this might depend on specialization), couldn't a -like API result in much faster code over something that requires calling a closure?
You'd just use for Copy types, but I'd expect to be literally identical to . Calling a function isn't really any different from calling a closure.
The team discussed this today and feel like would be preferable.
I've submitted implementing in order to help move this forward.
Any updates on this? Is there anything blocking this issue?
Only concern is whether to keep now that exists. But it looks like can go in FCP regardless.
so this has been in nightly for two months. What's the next step?
I see people frequently use unsafe because the safe is not fast enough. I've already talked about how this has almost resulted in a vulnerability in my post, but now I have discovered an actual vulnerability in another crate. So I am very interested in the "better compiler optimizations" part if it extends to numeric types such as . Or, if there is a different safe idiom for writing to a preallocated vector, I would love to hear about it.
I have a . Okay, the type is lying a little. I have a Vec of HashSets using the RandomState (default) hasher. The RandomState hasher is Clone, but using Clone to fill in a Vec has a serious caveat: all HashSets would have the same RandomState internal state. This runs a risk of exposing the system to DoS attacks. This is a very good reason to have or w/e in addition to . Anyway, guess I'll be using a loop.
I just wanted this on , because wants , which I don't have, but would work great.
Are you still happy with , as you were in Is there any additional work can do to help this along towards FCP?
I'm happy with resize_with personally! fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Why does the VecDeque one require ?
Seems like the method ended up in the wrong impl block by accident. We definitely don't want that bound.
:bell: This is now entering its final comment period, as per the . :bell:
This should add both resizewith and resizedefault for the reasons I mentioned above.
The FCP is for only. is not affected by the hash DoS you described.
There are usability/discoverability concerns with resize_with
If the FCP is just for could someone update the issue title?
Good catch Mea culpa. Fix up in
The final comment period, with a disposition to merge, as per the , is now complete.
Reactivating because still points here. Any thoughts on what should be done with ?
It’s the same as and was before we considered , right? Unless someone argues otherwise I’d be inclined to deprecate and remove.
It's equivalent, but not the same. v.resize_default is more user-friendly!
Is anyone using currently? Would love to here some experiences from people.
Isn't some kind of completion of the methods? Don't know if my comment really make sense.
And is like . We're not sure if we need a default version.
So, if we deprecate the method, why not the / ones? I am probably splitting hairs, but...
If the matter is open to discussion: I find that writing or even is too verbose and less communicative of the intent than writing the shorter and clearer . As pointed out, there's a reason we have an .
Is there any reason not to stabilize this right now? Offering functions that do the same thing as another function but with fewer arguments is a very common thing, and it's zero-cost in Rust.
I'd like to have resizedefault. I'm about to use it in one of my projects, plus I think it's good to have pairity with the other ordefault methods, like and EDIT: I forgot one of my favorites, (which is just )
I like resize_default, it's very clear and more newbie friendly.
I disagree! is such a common operation it is nice to have a short way of writing it. And as mentioned there are plenty of other convenience methods in Rust. What exactly is the problem with leaving it in? Edit: When I say "leaving it in", I actually thought it was already stable (haven't compiled code yet). I discovered it through rust-analyzer's autocomplete, thought "resizedefault? Yes that's exactly what I want". Some empirical evidence for discoverability argument. No way would autocomplete have suggested and honestly I'd have had to have googled how to do it if that was the only way. Or realistically I would have just done which is rubbish.
From a quick search on ([lang][0]=Rust), I decided to categorize every line using . There was one usage from crate that I'm pretty sure is an UB. After determining what is the type created by , I noticed it's , which shouldn't be constructed, and another approach should be used to have a zeroed allocation.
Thanks for the info If the majority of calls can use then that would support having a specialized method for that case.
For completeness I've scanned for uses of , exact command used was . Here are the results: At a glance the results seem to align with the ones posted above - roughly half of the invocations just use the default value. On the other hand, there are just 207 uses of across the entire ecosystem, so I'm not sure adding another method for a relatively niche use case is worth it.
For reference, occurs times and 6286 times.
for reference, how many unwrapor with the default value for the type (, , etc)? how many unwrapor_else with Default::default? is it possible that the problem is elsewhere? (bad docs, bad book, we failed our users?)
Here are all occurrences of and methods for your perusal: My point is, since the use of is very rare, I'm not convinced adding further sugar for it is worth it.
I think the point is that there are several other methods so it should be present for consistency and discoverability, even if it is rarely used. I'm pretty sure is very rarely used but it would be weird to omit it when exists.
can be specialized for using
That's currently done for , so I suspect it could then be done for without needing a separate method. (That said, it might be interesting to have a or or something once safe transmute can give a trait bound for which it's safe to initialize elements with zeros.)
In generic environment, with 'Vec<T' where 'T: Default', you can use either '.resizedefault()' or '.resizewith(Default::default())', the former can be specialized for integers and later not.
has been shipped in stable, and was deprecated and removed in favor of .

Discussion:
/// # Examples /// /// ``` <del> /// #![feature(vec_resize_with)] /// </del> /// use std::collections::VecDeque; /// /// let mut buf = VecDeque::new();

/// buf.resize_with(5, || { state += 1; state }); /// assert_eq!(buf, [5, 10, 101, 102, 103]); /// ``` <del> #[unstable(feature = "vec_resize_with", issue = "41758")] </del> <ins> #[stable(feature = "vec_resize_with", since = "1.33.0")] </ins> pub fn resize_with(&mut self, new_len: usize, generator: impl FnMut()->T) { let len = self.len();

/// # Examples /// /// ``` <del> /// #![feature(vec_resize_with)] /// </del> /// let mut vec = vec![1, 2, 3]; /// vec.resize_with(5, Default::default); /// assert_eq!(vec, [1, 2, 3, 0, 0]);

/// /// [`resize`]: #method.resize /// [`Clone`]: ../../std/clone/trait.Clone.html <del> #[unstable(feature = "vec_resize_with", issue = "41758")] </del> <ins> #[stable(feature = "vec_resize_with", since = "1.33.0")] </ins> pub fn resize_with<F>(&mut self, new_len: usize, f: F) where F: FnMut() -> T {

#![feature(optin_builtin_traits)] #![feature(nll)] #![feature(allow_internal_unstable)] <del> #![feature(vec_resize_with)] </del> #![feature(hash_raw_entry)] #![feature(stmt_expr_attributes)] #![feature(core_intrinsics)]