I'm concerned about the performance implications of PR #16999, which makes a copy any BigFloats or BigInts when doing deepcopy. The rationale for doing so is that somebody might bypass the BigInt and BigFloat types, and directly operate on their GMP/MPFR internals.
A few comments here (since I can't comment in-line at #16999). @rfourquet: LGTM and +1, as I think the other fix by SPJ was a bit dangerous as it is unavoidable that some people will break over the officially asserted immutability of BigInt/BigFloat, for efficienty reasons (i.e. need adeepcopy of x and then mutate the copy using gmp/mpfr library functions). If they are doing things for efficiency reasons, then they will not want to be unnecessarily doing copies of BigInt and BigFloat in this fashion, because this means that any time you are doing a deepcopy of an array (for example, so that you can sort it), you end up 1) allocating a new Julia object 2) allocating memory managed by GMP/MPFR 3) adding a finalizer for every number copied. I can do a benchmark later to show just how much that would cost (and can be prohibitive if you are dealing with millions of big numbers). Are there any examples in any of the packages of people directly operating on the internals of `BigInt`s or `BigFloat`s where this would be an issue? There definitely are people who were using `deepcopy` because they needed the arrays copied, before the arrays were modified. Now they would need to make their own "deepcopy", that only copied the containers, and not the elements which are supposed to be scalar numbers. As far as the dangerousness, there is the same issue with strings, which by convention are immutable, but by implementation are not. If you started directly modifying the internal .data field, you would definitely break a lot of code. Unfortunately, there is no way currently of enforcing this type of invariant in Julia. -Scott
