compile time garbage collection

[via Digitalmars-d]

On Sunday, 3 May 2015 at 04:46:52 UTC, ketmar wrote:
> i don't thing that such pass in general worth the efforts. D 
> programmers
> tend to use structures for local and short-lived objects. if i 
> did `new`,
> chances are that i really want it on heap, and it will not be 
> optimisable

This is where one have to decide whether to make a low/system 
level language with programmer control or a high level language 
with compiler control.  If you have GC by default, then it makes 
a lot of sense to not even have a stack conceptually and do 
explicit allocations and stack allocation as an optimization.

But yeah, a system level language should allow threads to be 
terminated which would prevent destructors from being called, and 
since GC call destructors on another thread it will change 
program behaviour to turn GC allocations into stack allocations 
in general...

> so it can catch very rare cases for the cost of expensive 
> interprocedural
> analysis. this makes some sense for C++, though.

Well, if D is to be a higher level language than C++, then it 
makes more sense for D. Especially since a "threaded view" 
through "non-shared" objects could allow better analysis, but 
that would require a 100% ban on transferring "non-shared 
pointers" to "shared pointers".

D really needs to get a well defined memory model.