Tracking issue for Vec::resize_with and resize_default

[joshlf]

Currently, Vec has a resize method which takes a new parameter so that if the resize involves growing the vector, the new parameter is cloned into each newly-created cell in the vector. T must implement Clone in order for this method to be available.

It would be useful to add a resize_default method that instead requires that T: Default, and calls T::default() to fill the newly-created cells. Not only would this be ergonomic, but for certain implementations of T::default, it might allow the compiler to make better optimizations.

[clarfon]

This would be an interesting addition for types which support Default but not Clone. I'll try and make a PR for it.

In the future, just FYI, feature requests should go in the RFCs repository.

[joshlf]

Ah OK, noted. That's even for feature requests like this one that don't deserve an RFC?

[clarfon]

Yep! The general rule is either PR here or RFC elsewhere.

Also, @joshlf would you mind renaming this issue to "Tracking issue for Vec::resize_default" ?

And @nikomatsakis would you mind tagging it?

[joshlf]

Gotcha; thanks!

[Mark-Simulacrum]

@rust-lang/libs 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 Clone and Default are the two "producing" traits in std, so standardizing around them seems logical.

fn resize_with(&mut self, new_len: usize, f: F)
where F: FnMut() -> T

[clarfon]

@Mark-Simulacrum I'd be willing to make a PR that adds resize_with under a separate feature flag. I think that all three are useful; resize_default would simply be documented as equivalent to resize_with(Default::default)

[sfackler]

I might lean more towards just having resize_with, for now at least. It's strictly more powerful and doesn't seem all that more verbose than resize_default?

[joshlf]

My concern is that resize_with hampers discoverability - you have to come across resize_with and then connect the dots to realize that you can do resize_with(Default::default). 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.

[djc]

Discoverability is pretty easily fixed by just having some documentation, though, right?

I like the power of resize_with, but I'm wondering about optimizability. Especially for Copy types (I guess this might depend on specialization), couldn't a resize_default-like API result in much faster code over something that requires calling a closure?

[sfackler]

You'd just use resize for Copy types, but I'd expect resize_with(Default::default) to be literally identical to resize_default. Calling a function isn't really any different from calling a closure.

[sfackler]

The @rust-lang/libs team discussed this today and feel like resize_with would be preferable.

[djc]

I've submitted #49559 implementing Vec::resize_with() in order to help move this forward.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[scottmcm]

Reactivating because https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.resize_default still points here.

Any thoughts on what should be done with resize_default?

[SimonSapin]

It’s the same as v.resize_with(Default::default) and was added before we considered resize_with, right? Unless someone argues otherwise I’d be inclined to deprecate and remove.

[SoniEx2]

It's equivalent, but not the same.

v.resize_default is more user-friendly!

[clarfon]

Is anyone using resize_default currently? Would love to here some experiences from people.

[Kerollmops]

Isn't Vec::resize_default some kind of completion of the Option/Result::unwrap_or_default methods? Don't know if my comment really make sense.

[clarfon]

@Kerollmops And resize_with is like unwrap_or_else. We're not sure if we need a default version.

[Kerollmops]

So, if we deprecate the Vec::resize_default method, why not the Option/Result::unwrap_or_default() ones?
I am probably splitting hairs, but...