RFC: moving forward with @nogc Phobos

[Andrei Alexandrescu via Digitalmars-d]

On 9/30/14, 6:53 PM, Manu via Digitalmars-d wrote:
> I generally like the idea, but my immediate concern is that it implies
> that every function that may deal with allocation is a template.
> This interferes with C/C++ compatibility in a pretty big way. Or more
> generally, the idea of a lib. Does this mean that a lib will be
> required to produce code for every permutation of functions according
> to memory management strategy? Usually libs don't contain code for
> uninstantiated templates.

If a lib chooses one specific memory management policy, it can of course 
be non-templated with regard to that. If it wants to offer its users the 
choice, it would probably have to offer some templates.

> With this in place, I worry that traditional use of libs, separate
> compilation, external language linkage, etc, all become very
> problematic.
> Pervasive templates can only work well if all code is D code, and if
> all code is compiled together.
> Most non-OSS industry doesn't ship source, they ship libs. And if libs
> are to become impractical, then dependencies become a problem; instead
> of linking libphobos.so, you pretty much have to compile phobos
> together with your app (already basically true for phobos, but it's
> fairly unique).
> What if that were a much larger library? What if you have 10s of
> dependencies all distributed in this manner? Does it scale?
>
> I guess this doesn't matter if this is only a proposal for phobos...
> but I suspect the pattern will become pervasive if it works, and yeah,
> I'm not sure where that leads.

Thanks for the point. I submit that Phobos has and will be different 
from other D libraries; as the standard library, it has the role of 
supporting widely varying needs, and as such it makes a lot of sense to 
make it highly generic and configurable. Libraries that are for specific 
domains can avail themselves of a narrower design scope.


Andrei