Implement Clone for all Copy types "by magic"

[DemiMarie]

This probably needs an RFC, but one solution to the problem of Copy not implying Clone is to make this happen via compiler magic: the compiler "magically" inserts an implementation of Clone for any Copy type.

GHC does something similar with Coercible.

[retep998]

Due to RFC 1521, we're allowed to assume that a Clone impl for Copy types is trivial and can be optimized out. Having the compiler automatically add trivial memcpy Clone implementation for all Copy types should be safe. As well there shouldn't be a backwards compatibility hazard as it would only allow more code to compile.

[bstrie]

Seems a bit magical, is the intent of this simply to allow one to type #[derive(Copy)] instead of #[derive(Copy, Clone)] ?

[durka]

@bstrie also to fix the bug where large arrays and tuples are Copy but not Clone.

[DemiMarie]

@bstrie The latter is actually the main purpose. Also to fix the ICEs that can result from a type being Copy but not Clone.

I do wish that this could be done in libcore as something like

impl<T: Copy> Clone for T {
  fn clone(&self) {
    return self;
  }
}

[sfackler]

This feels maybe doable with specialization, though I think it might require the lattice rule.

At the moment, we don't want to use specialization in a way that adds functionality that can't exist without it since the feature's unstable.

[durka]

I've never seen it tried, but yeah, whenever this comes up in the context
of specialization that seems to be the prevailing wisdom.

AFAIU the proposal here is to do it by magic, to eliminate concerns over
whether specialization is powerful and/or stable enough.

It's a good idea if we want to commit to the fact that large arrays and
tuples WILL be Clone... somehow... eventually. It's a bad idea if we could
contemplate fixing the bug some other way, like by making those types
non-Copy (a breaking change). There are also other ways to fix the bug,
like type-level integers, or even halfway type-level integers that I've
seen proposed (where you can impl for [T; _] but you can't refer to N
directly).

On Tue, May 10, 2016 at 12:21 PM, Steven Fackler notifications@github.com
wrote:

This feels maybe doable with specialization, though I think it might
require the lattice rule.

At the moment, we don't want to use specialization in a way that adds
functionality that can't exist without it since the feature's unstable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#33507 (comment)

[retep998]

It's a bad idea if we could contemplate fixing the bug some other way, like by making those types non-Copy (a breaking change)

Please no! This would break so much^†!

^†Mostly winapi.

[DemiMarie]

Yes, the idea here is to do it purely by compiler magic.  My intent is
for the magic to be temporary, and to be removed when it becomes
possible to implement in libcore.
This is similar to the magic typing rules for std::mem::transmute (I
believe that there is no other way to write code that compiles if and
only if two types are the same size).
On Tue, 2016-05-10 at 09:27 -0700, Alex Burka wrote:

I've never seen it tried, but yeah, whenever this comes up in the
context
of specialization that seems to be the prevailing wisdom.

AFAIU the proposal here is to do it by magic, to eliminate concerns
over
whether specialization is powerful and/or stable enough.

It's a good idea if we want to commit to the fact that large arrays
and
tuples WILL be Clone... somehow... eventually. It's a bad idea if we
could
contemplate fixing the bug some other way, like by making those types
non-Copy (a breaking change). There are also other ways to fix the
bug,
like type-level integers, or even halfway type-level integers that
I've
seen proposed (where you can impl for [T; _] but you can't refer to N
directly).

On Tue, May 10, 2016 at 12:21 PM, Steven Fackler
b.com>
wrote:

This feels maybe doable with specialization, though I think it
might
require the lattice rule.

At the moment, we don't want to use specialization in a way that
adds
functionality that can't exist without it since the feature's
unstable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

237>

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[Mark-Simulacrum]

I'm going to close this issue, since this is not the right place for it. If someone wants to pursue this, please follow the RFC process here https://github.com/rust-lang/rfcs#before-creating-an-rfc.