-
Notifications
You must be signed in to change notification settings - Fork 966
Should 32 byte Copy types be pass by reference or value? #708
Description
Creating a new issue to bring in more attention to this.
Pasting some relevant comments from #707 .
Sanket1729:
I think we should only pass by value when you give up ownership and I see no reason to do it here. And passing by reference when you temporarily relinquish ownership. I know it's tricky when things are Copy, but that's how it's currently implemented for the rest of the address APIs.
As an extereme, I don't think passing an [0u8; 100000] by value makes sense if we just want to access its elements without any ownership.
@Kixunil To the best of my knowledge, Copy types should be passed by value and it should be the job of the compiler to figure out whether using a pointer internally is better. If it doesn't do that, I'd consider it a compiler bug.
I'd agree with making exception for Option<&Large> as I don't expect the compiler to be able to also do null optimization.
If you have some resources that indicate something else I'd be happy to learn.
Sanket1729: My benchmarks say that it does not matter. They are very close in performance and within error of measurement to say if it really matters or not. However semantically, it makes sense to not pass by value because none of the underlying methods require references.
I would 100% support this provided we have underlying rust-secp APIs that require passing by value. What do you think?"
It would be good to get some consensus on this because this is kinda a blocker on the upcoming taproot release.