ARC: deepCopy in new runtime feature missing, do we have alternatives?

[cooldome]

Old runtime has deepCopy function that doesn't exist in new runtime, but I don't see alternatives to it.

The problem is I need to copy the XmlParser object from xmlparser to save its state. In order to save state of XmlParser I have used deepCopy in old runtime, because standard copy doesn't work as XmlParser contains Stream which is ref only object.

Things I tried as workaround and they don't work:

1. Try changing Stream to be non ref object. Stream ref hides the actual type of stream so it can't be not a ref object.

2. Add custom copy assignment operator to XmlParser. Can't be done because, ref hides actual stream type and you don't know how to copy it if you don't know object type.

I don't see alternatives to deepCopy function in presence of ref RooObj when you don't know what is behind the ref.

IMO, we have to provide deepCopy function that will be copy the content of the ref T and possibly ptr T. Fallback to standard copy operator when deepcopy specialization for type is not available.

Any thoughts how it can be achieve in any other way?

[Araq]

I'm afraid there is no better way esp considering that deepCopy is also still useful for multi-threading, ARC or not.

[ghost]

From https://github.com/Yardanico/random-stuff/issues/1 - libraries like https://github.com/NimParsers/parsetoml, https://github.com/PMunch/nim-persistent-vector depend on deepCopy

[cooldome]

What to do if the object appears as non ptr/ref inside other object?
Generate:

   let tmp = `=deepCopy`(addr(x))
   `=sink`(result,  tmp[]) 
   `=destroy`(tmp)

Looks bad do you have better ideas?

Problem 2.
ref T type needs runtime dispatch before calling =deepCopy, so you need the trampoline before the call.
Should it be added to every =deepCopy call of ref T type? should I place trampoline say in deepCopy proc instead and disallow direct =deepCopy calls.

[cooldome]

adding @Clyybber to discussion

[cooldome]

Anyone?

[krisppurg]

I think we should just wait for about 3 months and see if we have any similar ways to this.

[Araq]

@cooldome One new idea that I had is to clearly separate the old RTTI from the new RTTI in the backend and if required (getTypeInfor, deepCopy) trigger the code generation for the old RTTI once again. The new RTTI object should have a single pointer to the old RTTI (which is usually nil). Then we still need to patch the required places in system.nim to deal with a double indirection for ARC but it could work.

[ghost]

@Araq can this be closed since --deepCopy is now available for arc/orc?