Derive Clone for Keypair?

[Sushisource]

Is there any particular reason that the Keypair struct doesn't derive Clone? I have a spot where I need to clone one, and I've resorted to doing to_bytes->from_bytes which feels less than great.

If there's not a particular reason, I'd be happy to make a PR. Thanks!

[isislovecruft]

It's my understanding (please correct me if wrong!) that if we implement Clone then the Drop methods will still be recursively called. If so, it should be safe to implement Clone for Keypair (with the caveat that programmers who explicitly do this will temporarily have more copies of the SecretKey sitting around in memory.. which.. isn't the best). I'd like to ensure in some sense that programmers are disinclined to do this somehow, but I'm not sure how best to, which is why I've not a #[derive(Clone)] for SecretKey thus far.

[Sushisource]

@isislovecruft I figured that wanting to avoid extra copies in memory was probably the reason.

I can't think of any really great mechanism for that, besides maybe not actually implementing the Clone trait, and just having a special function for it, but that has a variety of associated issues.

🤷‍♂️ The other way to look at it is people who want to clone one are gonna do it anyway (like I did), so just make things clear in the docs and leave it at that?

[trevyn]

I'd like to ensure in some sense that programmers are disinclined to do this somehow, but I'm not sure how best to, which is why I've not a #[derive(Clone)] for SecretKey thus far.

I think you could put this behind an opt-in crate-level feature (say, cloneable_secret_key) that would make programmers think twice about enabling it. If this sounds reasonable, I could verify that the approach works and make a PR.