@Araq' Thanks for the further data on `async` using ref counting GC - I didn't realize it only worked without the cycle detector and a further "tiny" code gen patch.
> So we need a way to duplicate owned refs that still guarantees cycle freedom, > statically. I know that's what you're proposing via a `=deepCopy` for > `owned`... Perhaps we should stop calling what I proposed as `deepCopy` using `=deepCopy` as I just grabbed that term as as being the location where "outer" ref counting would be injected. Perhaps that would be the "hook" whereby my proposal could be best implemented, maybe not... > but I don't know if it can work out. **So how to test this and what code base to test it against?** I am probably able to do some patches against the current devel branch if they don't include code gen/"compiler magic" but I would prefer to leave any AST manipulations to you and your dev team as I have little experience in that area. I have held off doing too much in the way of experiments as I would like to include ""\--seqsv2", but I suppose that isn't really necessary as that was implicitly turned on in "\--newruntime". I guess I'll start with some copying experiments somewhere combining use of copying `seq`'s, `string`'s, closures containing `ref`'s, and `ref`'s. It would seem to be easy to test it I just new how to "hook" into the disposal of `ref`'s when at the end of `proc`'s in the way that "nominal" types get the "hooks" called now. **I would like to work within the framework of the ``=destroy``, ``=``, ``=sink``, and ``=destroy`` "hooks" but as applied to ``ref``'s and not to just "nominal" types. Would this be possible?** **Is there a place in the code that could make these "hooks" readily accessible to me?**
