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 a deepcopy_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.