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

Under what conditions can you implement Copy for a union? #65748

Closed
Centril opened this issue Oct 24, 2019 · 10 comments

Comments

@Centril
Copy link
Member

@Centril Centril commented Oct 24, 2019

From #32836 (comment):

Under what conditions can you implement Copy for a union? For example, what if some variants are of non-Copy type? All variants?

@RalfJung notes in #55149 (comment) that:

The RFC doesn't say anything about that, but I think indeed the answer should be "all variants".

cc #55149

@petrochenkov

This comment has been minimized.

Copy link
Contributor

@petrochenkov petrochenkov commented Oct 24, 2019

the answer should be "all variants".

+1
If Copy is implemented for a union with non-copy fields, it undermines all the remaining move/initialization checking for unions.

@RalfJung

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung commented Oct 24, 2019

I still think the same way.

unsafe impl Copy for semi-regularly comes up, but I do not see any reason to tie it to unions.

@Centril Centril added the I-nominated label Oct 24, 2019
@Centril

This comment has been minimized.

Copy link
Member Author

@Centril Centril commented Oct 24, 2019

The current behavior does fortunately seem to enforce the "all variants" behavior:

#![feature(untagged_unions)]

struct NoCopy;

#[derive(Clone, Copy)]
struct IsCopy;

#[derive(Clone, Copy)]
union U {
    a: NoCopy,
    b: IsCopy,
}

results in an error:

error[E0204]: the trait `Copy` may not be implemented for this type
  --> src/lib.rs:8:17
   |
8  | #[derive(Clone, Copy)]
   |                 ^^^^
9  | union U {
10 |     a: NoCopy,
   |     --------- this field does not implement `Copy`

I agree that it is a sensible conservative default.

@varkor

This comment has been minimized.

Copy link
Member

@varkor varkor commented Oct 24, 2019

There don't seem to be any sensible alternatives to the current behaviour. What else could the condition possibly be?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented Oct 24, 2019

@rfcbot fcp merge

We discussed this in today's @rust-lang/lang meeting and we all felt that this behavior seemed like the obvious and correct one. It is also the one that is presently implemented. Moreover, it's a conservative choice -- if we wanted to permit Copy impls under more conditions, we could do so at some later point. Therefore, I move that we "merge". (Since the behavior is already implemented, no changes are needed -- though one good question is whether we have suitable tests.)

@rfcbot

This comment has been minimized.

Copy link

@rfcbot rfcbot commented Oct 24, 2019

Team member @nikomatsakis 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 at most 2 approvals are outstanding), 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.

@petrochenkov

This comment has been minimized.

Copy link
Contributor

@petrochenkov petrochenkov commented Oct 24, 2019

The current behavior is not accidental and it has a test (union-copy.rs).

@rfcbot

This comment has been minimized.

Copy link

@rfcbot rfcbot commented Oct 24, 2019

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

@rfcbot

This comment has been minimized.

Copy link

@rfcbot rfcbot commented Nov 3, 2019

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

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@Centril

This comment has been minimized.

Copy link
Member Author

@Centril Centril commented Nov 4, 2019

Moving all remaining work to the reference in rust-lang/reference#709 now that FCP is complete.

@Centril Centril closed this Nov 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.