Change:
/// Basic usage: /// /// ``` <del> /// #![feature(repeat_generic_slice)] </del> /// assert_eq!([1, 2].repeat(3), vec![1, 2, 1, 2, 1, 2]); /// ``` /// /// A panic upon overflow: /// /// ```should_panic <del> /// #![feature(repeat_generic_slice)] </del> /// // this will panic at runtime /// b"0123456789abcdef".repeat(usize::max_value()); /// ``` <del> #[unstable(feature = "repeat_generic_slice", reason = "it's on str, why not on slice?", issue = "48784")] </del> <ins> #[stable(feature = "repeat_generic_slice", since = "1.40.0")] </ins> pub fn repeat(&self, n: usize) -> Vec<T> where T: Copy { if n == 0 { return Vec::new();

Discussion:
There exists a  method, but no equivalent for (byte) slices. This would seem like a useful feature. Should we consider adding it to the stdlib?
Possibly generalized (or not, but let's entertain the notion...)
Seems reasonable to add this to .
Heh, I should expect something abstract from you! Could definitely do that, and implement it even for things like iterators, though it's a bit more work... Yep, that certainly wouldn't be too liberal
Doesn't the general one exist already? That said, could easily be moved to , and that way the str/String version would just wrap the slice/Vec version. That seems like a more interesting option to me, since it's taking advantage of the "slice-ness", rather than just being a wrapper around iterator methods.
What's the efficiency of that one like? I bet it's nothing close to , which could effectively be done by specialising on for .
That's what I meant by my second paragraph. sounds great, but I don't see a need for it for iterators or T: Clone.
Yeah, that's certainly a fair idea. Do you know if is as efficient as pre-allocating a of the requisite size and repeatedly calling on it? If so, I agree with you fully. Otherwise, there may be a need for a trait.
We can implement it for and specialize to 's implementation for . None of that needs to affect the method's public API though.
Yep, that sounds like a good solution to be honest. Even if it's no more efficient that the iterator approach for , it would at least provide a consistent interface!
Unfortunately I know for sure that literally is unlikely to be great (see for a discussion of why, though that PR wouldn't help this case). But I would expect that using instead would let the iterator method do just as well as something more manual.
Fair enough, though I think in that case why might as well provide that as a default fn on the trait, and allow for specialisations when (and potentially other cases too).
poll I'd like to stabilize . The signature in is and the implementation uses on which relies on the property of . There's to generalize the bound to , however I don't think this is a stabilization blocker: is what makes special. If , the performance is probably just similar to and can be used instead.

is a subtrait of , we can upgrade the bound to without breaking backward compatibility. OTOH it is really simple to extend the bound to today as we could use specialization internally (as explained in ):
Team member has asked teams: T-libs, for consensus on: [x] [x] [x] [x] [ ] [ ]
From the implementation: I guess that it’s this way because fewer calls to with larger slices are assumed to be faster. This may be the case up to "medium" sizes compared to e.g. copying a single byte at a time. However at some point, going back "far away" in memory might hurt cache locality. Do we have evidence one way or another to justify such complex code?
Is there anything blocking stabilization here? It looks like comment above here is "just" an implementation nit.
The code came from , which has some performance numbers in the PR that this implementation method:
Right, my comment should not be taken as blocking stabilization. It’s purely an implementation detail and can change later. This pFCP awaits your checkboxes above.
I came across this again and read through the comments to find nothing blocking stabilization other than your votes which have been absent for 9 months. It would seem prudent to comment before it is further forgotten.
is a poll, not a pFCP. These days rfcbot starts FCP when it has not more than two check boxes missing, so I think this one should be considered accepted. Feel free to send a stabilization PR.
I confirmed that run-time of with larger or gets worse. <details </details
Would you be interested in working on a PR to improve the implementation?
Yes, I'll try to add the fallback to the old impl for large parameters.
It may be worth looking at the number of bytes being copied per loop iteration, rather than simply the number of repetitions.