On Thursday, 13 November 2014 at 10:38:57 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz
wrote:
Huh? That's exactly what _borrowing_ does. Ref-counting OTOH
adds yet another reference type and thereby makes the
situation worse.
I don't like explicit ref counting, but it is sometimes useful
and I think Rust-style ownership is pretty close to unique_ptr
which is ref-counting with a max count of 1… You can also view
GC as being implicitly ref counted too (it is "counted" during
collection).
I think I understand now how you want to use templates. You
basically want to make the various reference types implement a
protocol, and then templatize functions to accept any of those
reference types, just like we do with ranges.
But this brings with it the downside of templates, namely
template bloat. And you need to do additional work to eliminate
all the redundant inc/dec calls if you pass an RC reference. All
of which is unnecessary for most functions, because a function
knows in advance whether it needs to retain the reference or just
borrow it, and can be declared accordingly. This means that
`scope` acts as an abstraction over the various reference types,
be it GC, RC, plain pointer, unique pointer, or some more
complicated user defined scheme.
This also benefits the GC, by the way. A scope reference doesn't
need to be treated as a root, because there will always be at
least one other copy of the reference. This means that structures
containing only scoped references need not be scanned.
What does "shared" tell the compiler?
I guess you mean "scope"?
:)
It tells it "retain no references after completion of this
function". Like with "pure", it should be opposite. You
should tell the compiler "I transfer ownership of this
parameter". Then have a generic concept "owned" for
parameters that is resolved using templates.
That's what deadalnix's proposal does. Though I don't quite
see what templates have to do with it.
My understanding of Deadalnix' proposal is that "owned" objects
can only reference other "owned" objects.
Yes. But they can also be merged into un-owned structures (i.e.
the various heaps), at which point they lose their owned-ness.
This allows the creator of these objects to be agnostic about how
the consumers want to handle them.
I think region allocators do better if you start constraining
relations by ownership.
Not sure what you mean, but I don't think region allocators can
be used for this. They require the object creator to know in
advance how long the objects will exist. Or alternatively, the
creators need to be informed about that by receiving a reference
to the region allocator, at which point we're most likely back at
templates.
