可能であれば、コピー特性を常に実装する必要がありますか？

Question

Copyの特性を実装して、move-semanticsではなくcopy-semantics型を与えることができます。これは、そのすべての構成要素（製品タイプの各因子、または合計型の各変種の各因子）もCopyである場合にのみ実行できます。

これにより、かなり大きいタイプのCopyも作成できます。タイプのサイズが「大きい」場合は、Copyを実装するとパフォーマンスに悪影響を及ぼすことがありますか？

Copyた場合は常に、なぜそれが代わりにオプトインのそれを実装し、オプトアウトのセマンティクスを持つことができ、これらのタイプのSyncとSendなどの自動特色はありませんが、実装すべきですか？

Answer 1

なぜそれを実装し、オプトアウトのセマンティクスの代わりにオプトインを持つことができ、これらのタイプのSyncとSendのような[Copy]ない自動特色がありますか？

Copyは、それを実装できるタイプによって自動的に実装されていました。この動作はin December 2014に変更されました。

可能であれば、Copy特性を常に実装する必要がありますか？

必ずしもそうである必要はありません。ライブラリを開発する場合、タイプにCopyを実装するかどうかは、前方互換性に影響します。あるタイプのCopy実装を削除することは大きな変更です（そのタイプのユーザは、移動する代わりにコピーするタイプに依存する可能性があります）。そのため、semantic versioningを尊重するためにライブラリにメジャーバージョンのバンプが適用されます。特に、タイプがCopyを今実装できる場合、タイプが進化してCopyを実装できなくなる可能性があると思われる場合は、安全に再生し、そのタイプにCopyを実装しないでください。

Copyを実装しないもう一つの理由は、前述したように大きなタイプです。通常、「CloneではCopyではない」という値は、値のクローン作成が「安い」ではないことを示しているため、このようなタイプにはCloneしか実装しないと便利です。しかし、型がCopyでなくても、単に値を移動するだけで、大きなメモリコピー操作が発生する可能性があります（ただし、幸運なことに、コンパイラはそれを最適化するかもしれません）。

Copyを実装すると、タイプのサイズが「大きい」場合はパフォーマンスに悪影響を及ぼすことがありますか？

タイプでコピーを実行しない場合は、 の唯一の違いは、とのコピーの唯一の違いは、移動によってソースが使用できなくなることです（つまり、移動後に値を使用しようとするとコンパイラがエラーを発生させます） 't;両方の操作は、浅いメモリコピーとして実装されます。