manual memory management

[Rob T]

On Monday, 7 January 2013 at 17:19:25 UTC, Jonathan M Davis wrote:
> I don't think that any of the documentation or D's developers 
> have ever
> claimed that you could use the full language without the GC. 
> Quite the
> opposite in fact. There are a number of language features that 
> require the GC
> - including AAs, array concatenation, and closures.

True, there is some documentation describing that certain 
features require the use of the GC. Although I would say that the 
documentation needs to be made a lot more clear on this point. 
For example in the AA section there's no mention that the GC is 
required.

What you are saying is that while the GC is considered optional, 
it is not really optional given the language as a whole, only a 
(I assume large) subset of the language will work without the GC. 
In other words, the GC is partly optional.

I think we can do a lot better to make it more clear that the GC 
is not 100% optional, and also indicate clearly what features 
will not work without one.

>> You _can_
> program in D
> without the GC, but you lose features, and there's no way 
> around that. It may
> be the case that some features currently require the GC when 
> they shouldn't,
> but there are definitely features that _must_ have the GC and 
> _cannot_ be
> implemented otherwise (e.g. array concatenation and closures).

Is this a hard fact, or can there be a way to make it work? For 
example what about the custom allocator idea?

 From a marketing POV, if the language can be made 100% free of 
the GC it would at least not be a deterrent to those who cannot 
accept having to use one. From a technical POV, there are 
definitely many situations where not using a GC is desirable.

--rt