Disadvantages of ARC

[H. S. Teoh]

On Thu, Feb 06, 2014 at 04:47:05PM +0100, Johannes Pfau wrote:
[...]
> Some people seem to want some implicit way to set a 'default'
> allocator, but I haven't heard of any solution that works. (E.g. having
> a thread-local default allocator, per library default allocator, how
> would that even work?)
> 
> I don't think there's anything wrong with the obvious solution: All
> phobos functions which allocate take an optional Allocator parameter,
> defaulting to GC. The little extra typing won't harm anyone and if you
> want to use things like stack-based buffers you'll have to write extra
> code and think about memory allocation anyway.
> 
> auto gcString = toUpper("test");
> auto mallocString = toUpper!Malloc("test");
> ubtye[64] sbuf;
> auto stackString = toUpper(sbuf[], "test");
> 
> What's so bad about this? It works for most of phobos, doesn't require
> language changes and it's easy to realize what's going on when reading
> the code. Having an 'application default allocator' or 'thread local
> default allocator' or 'per function default allocator' will actually
> hide the allocation strategy and I bet it would cause issues.
[...]

I think a superior solution is to pass in an output range to toUpper,
that does whatever form of allocation you prefer. There's nothing about
toUpper that *fundamentally* depends on an allocator, therefore it
shouldn't even *care* what an allocator is. Reduced to its absolute
fundamentals, it just takes data from some input string, and produces
some output data. Where this output data goes is none of its concern --
it can be a GC string, an ARC string, stdout, an interprocess pipe, a
network socket, toUpper shouldn't have to care which one it is. Just
take an output range.

Then on the complementary side, have Phobos provide a bunch of premade
output ranges that allocates a GC string, or an ARC string, or whatever,
and then the user can just pick one of those to pass to toUpper.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen