More radical ideas about gc and reference counting

[via Digitalmars-d]

On Tuesday, 6 May 2014 at 06:07:41 UTC, HaraldZealot wrote:
> I have to say that all this discussion (more precisely the 
> understanding on the side of key developers) make me very upset.
>
> It's good that Andrei agreed with impossibility of the 
> harebrained disallowing of the class destructors. But I was 
> very surprise, that so thought go to such head, because such 
> solution contradicts the D spirit totally. There are many 
> language which are very popular and have many dark moments in 
> their design. I (and I think not only me) go to the D not for 
> its popularity, but for its clarity, power and SANITY (that 
> bases on strong guaranties). The strong solutions found on the 
> strong decision makes D itself. (Examples of such strong 
> solutions: immutabilities, default unshareness, struct and 
> class as distinct being). And way that leads us in state where 
> stucts have dtors and classes haven't but allow struct with 
> dtor as member and people have to call struct dtor manually, 
> isn't D way. Because such way relies on programmers discipline, 
> but how Andrei has written "If there one thing that decades of 
> computing have taught us, it must be that discipline-oriented 
> programming does not scale."[TDPL, p. 399].

Actually, IMO the clarity and sanity you talk about are a strong 
argument _for_ the deprecation of destructors for GC objects:

Premise 1: Destructors are for things that _must_ be done when an 
object is destroyed. Destroying (or leaking) an object without 
calling its destructor can (and often will) lead to wrong program 
behavior and is therefore an error.

Premise 2: Tracing GCs are by their nature non-deterministic and 
can not guarantee proper destruction of objects. This is true 
even if full type information about the managed objects is 
available (which is currently the case only for classes), as long 
as they are non-precise (which, realistically, in a systems 
programming language they will always be at least to some degree).

Conclusion: It's an error to have objects with destructors be 
managed by the GC. Per Andrei's quote about "discipline-oriented 
programming", this should therefore be made impossible.

(Apart from that, there are tons of things that you aren't 
allowed to do in a destructor called from the current GC, but 
there's currently no way to detect them statically => again 
"discipline-oriented programming".)

Of course, how exactly this is achieved is up for debate. Also, 
maybe one of the premises is false...