RFC: moving forward with @nogc Phobos

[Jacob Carlborg via Digitalmars-d]

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