On Thursday, 2 October 2014 at 06:29:24 UTC, Jacob Carlborg wrote:
@gc a = foo(); // a contains an instance of Foo allocated with
the GC
@rc b = foo(); // b contains an instance of Foo allocated with
the RC allocator
That would be better, but how do you deal with "bar(foo())" ?
Context dependent instantiation is a semantic challenge when you
also have overloading, but I guess you can get somewhere if you
make whole program optimization mandatory and use a
state-of-the-art constraint solver to handle the type system.
Could lead you to NP-complete type resolution? But still doable
(in most cases).
I think you basically have 2 realistic choices if you want
easy-going syntax for the end user:
1. implement rc everywhere in standard libraries and make it
possible to turn off rc in a call-chain by having compiler
support (and whole program optimization). To support manual
management you need some kind of protocol for traversing
allocated data-structures to free them.
e.g.:
define memory strategy @malloc =
some…manual…allocation…strategy…description;
auto a = bar(foo()); // use gc or rc based on compiler flag
auto a = @rc( bar(foo()) ); // use rc in a gc context
auto a = @malloc( bar(foo()) ); // manual management (requires a
protocol for traversal of recursive datastructures)
2. provide allocation strategy as a parameter
e.g.:
auto a = foo(); // alloc with gc
auto a = foo!rc(); // alloc with rc
auto a = foo!malloc(); // alloc with malloc
But going the C++ way of having explicit allocators and
non-embedded reference counters (double indirectio) probably is
the easier solution in terms of bringing D to completion.
How many years are you going to spend on making D ref count by
default in a flawless and performant manner? Sure having RC being
as easy to use as GC is a nice idea, but if it turns out to be
either slower or more bug ridden than GC, then what is the point?
Note that:
1. A write to a ref-count means the 64 bytes cacheline is dirty
and has to be written back to memory. So you don't write 4 bytes,
you write to 64 bytes. That's pretty expensive.
2. The memory bus is increasingly becoming the bottle neck of
hardware architectures.
=> RC everywhere without heavy duty compiler/hardware support is
a bad long term idea.
