* Araq (2008-2019) Let's create a new language, fast, bare metal and convenient combined, with a garbage collector. A garbage collector is a nice-to-have. No strict atomic ref counting, let's scan the Stack instead. People love Nim+GC from the very beginning. They mangle lifetimes all the time, because the GC is very liberal. And the sun is shining every day. * Araq(2019+) The GC has been good for a long time, but it is no good anymore. Let's shift to a strict monotonic order of lifetimes and real atomic refcounting. Every single alias gets refcounted now. Thanks to the fancy Bacon/Dingle stuff, 95% of the refcounts can be optimized away easily. Nim will become blazingly fast and the sun will shine even more. * Sixte (2019) Let's assume that Sixte is deaf, almost blind and very old. With his shaking hands he barely hits the keyboard but he desperately wants to support Araq's idea. Unfortunetely, Sixte is so blind that he sees types everywhere. He even looks at types that are not there. He sees the following:
> * a type N for `owned ref` (Node) > * a type U for `unowned ref` (Node) > * a type X for exchanged nodes, exchanged via proc parameter list > * a type R for returned refs; returned from a function call > * and (X,R) combines freely with (N,U) . So one can have an XU, an RN, but even a XN, a RU are possible. * a type A for (internally) aliased nodes stands for internal copies of a ref. This gives AXU, ARN etc... * a type F for Fields. (behaves very similar to X) * What if a call to another function is made? Well, the types have to be combined with X. For a RU, this gives XRU, for a RN it gets XRN. What about a XN that has to be passed to another proc? XXN? > * Introduction of a Fixpoint rule: X(X...N) = X(...N) , dito for U. Now, > XXXXXXN boils down to XN. What about a RN, if a XN is required? > * Well, subtyping rules: RN <:XN, RU <:XN come to help. But what, if the > callee wants a XRU instead? > * One might argue that this should never happen. But, in the darkest moments of the thread: [https://github.com/nim-lang/RFCs/issues/144](https://github.com/nim-lang/RFCs/issues/144) there was a talk about a `kill T` feature. Sounds horrible and it is. But the `kill T` feature requires a XRU. > * The kill T feature is transient: it runs "trough the procs" > * X(A....) reduces to X(....). The number of internal shares at callsite is > not of importance for the callee. > ...Back to daylight. These ghosts do not affect the normal user of nim. They have some importance on the dark side of power though.
