Am Wed, 05 Feb 2014 20:18:33 +0000 schrieb "Adam D. Ruppe" <[email protected]>:
> On Wednesday, 5 February 2014 at 19:39:43 UTC, Andrei > Alexandrescu wrote: > > You do figure that complicates usage considerably, right? > > I don't see much evidence for that. Many, many newer modules in > Phobos are currently allocation free yet still pretty easy to use. > > A major source of little allocations in my code is std.conv and > std.string. But these aren't difficult to change to external > allocation, in theory at least: > > string s = to!string(50); // GC allocates (I'd keep this for > convenience and compatibility) > > char[16] buffer; > char[] s = toBuffer(buffer[], 50); // same thing, using a buffer > > char[] s = toLowerBuffer(buffer[], "FOO"); > assert(buffer.ptr is s); > assert(s == "foo"); > > I think using a template parameter to allow for all kinds of allocators (std.allocator) is better. But of course it should have zero-overhead for a static-buffer allocator. Or we just special case static buffers _and_ add allocators ;-) But as Andrei said that discussion is not part of this thread. The main reason for RCSlice is not returning from Phobos functions, it's passing slices to Phobos functions. You can always create a RCSlice!string with any kind of string and as Andrei wants them GC-backed anyway, you can just create the RCSlice!string after the function returned a GC allocated string. (As long as the function doesn't keep a reference) But if we pass a RCd slice to a phobos function as a normal string, we'd have to stop reference counting. While this doesn't matter for GC-backed slices it basically means that manually allocated slices would never be freed. However, I wonder if that's really a problem in phobos. I'd guess most functions accepting slice input don't store a reference. We should probably start documenting that. (Or finish 'scope' as you already said implicitly ;-).
