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

Tracking issue for Option::copied #57126

Closed
xfix opened this Issue Dec 26, 2018 · 13 comments

Comments

Projects
None yet
8 participants
@xfix
Copy link
Contributor

xfix commented Dec 26, 2018

This is a tracking issue for Option::copied.

Added in #56534. Feature gate: #![feature(copied)].

Related feature: iter_copied in #57127.

@pmarcelll

This comment was marked as resolved.

Copy link
Contributor

pmarcelll commented Dec 26, 2018

Did you mean Option::copied in the first sentence?

@xfix

This comment was marked as resolved.

Copy link
Contributor Author

xfix commented Dec 26, 2018

@pmarcelll Fixed.

@alercah

This comment has been minimized.

Copy link
Contributor

alercah commented Jan 20, 2019

The map_clone lint in Clippy should be updated to suggest this instead when the type is copiable.

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 28, 2019

So we added a newtype Copied because that's what we usually do. However, in this case, we could simply reuse Cloned and implement copied as:

fn copied<'a, T>(self) -> Cloned<Self> where
    Self: Iterator<Item = &'a T>,
    T: 'a + Copy, 

Are there notable reasons not to do this that I'm missing? Doing so would substantially decrease the cost of this feature for the standard library.

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 29, 2019

Cloned type wouldn't have the guarantees that Copied does, as it calls the clone method, which can have side-effects (it shouldn't, but it's not something we can depend on).

Although I suppose we currently DO expose specialization in Cloned structure when Clone implementation is incompatible with Copy implementation. This seems like a bug, so I will fix that in a separate PR.

@xfix

This comment has been minimized.

Copy link
Contributor Author

xfix commented Jan 29, 2019

See #57970.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Feb 1, 2019

The comment about the Copied type belongs in #57127. Since I see no objection to Option::copied:

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Feb 1, 2019

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

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 this document for info about what commands tagged team members can give me.

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Feb 8, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Feb 18, 2019

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

@matklad

This comment has been minimized.

Copy link
Member

matklad commented Mar 15, 2019

Am I correct that this now awaits for a stabilization PR?

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Mar 15, 2019

Yes.

matklad added a commit to matklad/rust that referenced this issue Mar 16, 2019

@matklad

This comment has been minimized.

Copy link
Member

matklad commented Mar 16, 2019

Stabilization PR is up: #59231

kennytm added a commit to kennytm/rust that referenced this issue Mar 16, 2019

@bors bors closed this in #59231 Mar 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.