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

Slices don't implement copy. #30483

Closed
mahkoh opened this issue Dec 19, 2015 · 6 comments
Closed

Slices don't implement copy. #30483

mahkoh opened this issue Dec 19, 2015 · 6 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@mahkoh
Copy link
Contributor

mahkoh commented Dec 19, 2015

[T]: Copy where T: Copy

does not hold even though it could. Together with size_of_val, this would allow one to write various functions generic over all Copy types whether they are sized or unsized.

@mahkoh
Copy link
Contributor Author

mahkoh commented Dec 19, 2015

It's seems like Copy requires Sized but i don't see a reason for that either.

@eddyb
Copy link
Member

eddyb commented Dec 19, 2015

See #25776.

@mahkoh
Copy link
Contributor Author

mahkoh commented Dec 20, 2015

The case where I noticed this is the following:

trait Pod: Copy { }

That is,

  • Pod types can always safely be copied,
  • Pod types don't have to be unsized.

Both statements are true (given the definition of Pod used in lrs, unrelated to the Pod mentioned in the linked issue.) But I had to remove the Copy bound because I couldn't implement

impl<T: Pod> Pod for [T]

which is necessary because I want to implement

impl<T: Pod+?Sized> AsMut<[d8]> for T

The comment by @nikomatsakis seems to mostly address the cases where you're using Copy+?Sized directly, that is, where you care about Copy. But in the AsRef implementation I only care about the Pod aspect.

It seems that the built-in Sized bound can be removed in a backwards compatible way by adding an implicit Sized bound in libcore (should already exist via the Clone bound). If you then allowed Copy to be (explicitly) implemented for slices, the code above would work.

@cyplo
Copy link
Contributor

cyplo commented Jan 15, 2017

Any news on this one? Do we need RFC for it ?

@nikomatsakis
Copy link
Contributor

I am not sure whether I think we should permit sized types to be copy. I outlined some of my thoughts in this comment, which @eddyb already linked to. However, in the meantime, I've started to wonder if we should support moving and copying of DSTs just by using allocas at codegen time, which would allow us to make them work much more uniformly, almost like any other type. That would also make it fine for unsized types to be copy, though it might lead to footguns in some cases, but no different than a type like [u32; 1024] being Copy).

@steveklabnik steveklabnik added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed A-lang labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 24, 2017
@steveklabnik
Copy link
Member

Triage: given niko's last comment, I think I'm going to close this one too. It's been a few years, and this feels very much like a "needs an RFC" thing to me. Let me know if that's wrong. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants