Skip to content
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

retain improvements #2160

Closed
eira-fransham opened this issue Sep 20, 2017 · 6 comments
Closed

retain improvements #2160

eira-fransham opened this issue Sep 20, 2017 · 6 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@eira-fransham
Copy link

Firstly, I believe it would be sound for the function passed to retain to take a mutable reference instead of an immutable one. There is no real reason to restrict this. Additionally, I've found it useful to return the removed array as an &mut [T] - since all the elements are at the end anyway this is essentially free. In my case I only allow this when the elements are Copy (as a hack around not being able to specify !Drop), but it would be sound to allow Drop types. The issue is that it would unconditionally leak, which would be solved by an additional type that derefences to &mut [T] but that drops its elements on drop. It would have to take a lifetime parameter to disallow mutating the vector after returning the elements.

@ExpHP
Copy link

ExpHP commented Sep 22, 2017

The deficiency of retain supplying &T was discussed a while back, but nothing solid came of it.

@CryZe
Copy link

CryZe commented Sep 22, 2017

There's drain_filter on nightly which is very similar (except the condition is flipped).

@eira-fransham
Copy link
Author

I think drain_filter basically does exactly what I'm talking about - returning removed elements and taking &mut T. I think it might be better to return a slice-esque type that prevents mutating the vec while it's still alive though, since it's strictly more expressive. To get the behaviour of drain_filter you can then just do .into_iter(). I think it might be useful to have a slice type that owns its elements but not their storage, anyway.

@Centril Centril added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Dec 6, 2017
@Centril
Copy link
Contributor

Centril commented Oct 8, 2018

Now that https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.drain_filter is stable it seems that this is sufficiently fulfilled to close.

@Centril Centril closed this as completed Oct 8, 2018
@RReverser
Copy link

Now that doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.drain_filter is stable it seems that this is sufficiently fulfilled to close.

Maybe I misunderstand what "stable" meant in this context, but ~1.5 years later it seems to be still unstable / nightly-only?

@kennytm
Copy link
Member

kennytm commented Mar 22, 2020

Even if drain_filter is still unstable, discussion should be in rust-lang/rust#43244 rather than this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

6 participants