On 2014-09-29 12:49, Andrei Alexandrescu wrote:
Now that we clarified that these existing attempts are not going to work well, the question remains what does. For Phobos I'm thinking of defining and using three policies:enum MemoryManagementPolicy { gc, rc, mrc } immutable gc = ResourceManagementPolicy.gc, rc = ResourceManagementPolicy.rc, mrc = ResourceManagementPolicy.mrc; The three policies are: (a) gc is the classic garbage-collected style of management; (b) rc is a reference-counted style still backed by the GC, i.e. the GC will still be able to pick up cycles and other kinds of leaks. (c) mrc is a reference-counted style backed by malloc. (It should be possible to collapse rc and mrc together and make the distinction dynamically, at runtime. I'm distinguishing them statically here for expository purposes.) The policy is a template parameter to functions in Phobos (and elsewhere), and informs the functions e.g. what types to return. Consider: auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2 ext) if (...) { static if (mmp == gc) alias S = string; else alias S = RCString; S result; ... return result; } On the caller side: auto p1 = setExtension("hello", ".txt"); // fine, use gc auto p2 = setExtension!gc("hello", ".txt"); // same auto p3 = setExtension!rc("hello", ".txt"); // fine, use rc
How does allocators fit in this? Will it be an additional argument to the function. Or a separate stack that one can push and pop allocators to?
-- /Jacob Carlborg
