Open vchuravy opened 1 year ago
Imo deepcopy
is more trouble than it's worth and should probably be deprecated if not removed. https://github.com/JuliaLang/julia/issues/42796#issuecomment-951232853
Thanks for starting the conversation @vchuravy. Here is an example bug that can arise from naive use of deepcopy
: https://github.com/JuliaMath/FFTW.jl/issues/261. Here was the confusion prior to the correct diagnosis: https://github.com/JuliaLang/julia/issues/48722.
I meet @kbarros the other day and he recounted a story where he lost a lot of time on a tricky corner-case of
deepcopy
.We often use
mutable structs
with pointers to underlying foreign memory and attached finalizers for resource management. Users can thus easily get into the situation where they perform a deep copy of the struct and then GC frees the original copy, runs the finalizer and the user access the now release foreign memory through new object and has to deal with obscure crashes.We already deal with these situations on serialization, where we null out raw pointers. Once could think of deep copy as effectively doing a
deserialize(serialize(obj))
and thus I think it would be justifiable for deep copy to zero out raw pointers as well, and requiring folks to write adeepcopy_internal
method that deals with this situation.Due to the behaviour of
serialization
we already have users who check if the pointer is null and then either provide a user friendly error, or lazily re-initialize the foreign memory.@vtjnash mentioned on Slack that there was already an issue about this, but I was unable to find it.