flat reference counting with move semantics and destructors with single ownership,
optimized with sink and lent annotations for zero-copy all the way is annotated,
basically it is like a shared heap with subgraphs with a single owner, all this is done at compile-time, and ownership can be checked at run-time too.
Not really a GC despite --gc:.
Not really the same as Swift and ObjectiveC lang ARC because those can not handle cycles.
Not really Atomic despite ARC,
it wont need atomic reference counting,
a graph is always owned by a single owner,
then no need to make the reference counting atomic
(real atomic is known to be kinda slow).
Thanks and Yes, I'm aware. They did go all the way on the GC part 😜
Technically they all fit under definition of GC IMO. They don't have ARC or Ownership as far as I see
--gc:arcflat reference counting with move semantics and destructors with single ownership,
optimized with
sinkandlentannotations for zero-copy all the way is annotated,basically it is like a shared heap with subgraphs with a single owner,
all this is done at compile-time, and ownership can be checked at run-time too.
Not really a GC despite
--gc:.Not really the same as Swift and ObjectiveC lang ARC because those can not handle cycles.
Not really Atomic despite
ARC,it wont need atomic reference counting,
a graph is always owned by a single owner,
then no need to make the reference counting atomic
(real atomic is known to be kinda slow).
Well, in that case, it's just bad grouping coz ARC is not GC. And seems these are buried in the docs somewhere.