More radical ideas about gc and reference counting

[via Digitalmars-d]

On Thursday, 1 May 2014 at 15:28:25 UTC, Andrei Alexandrescu 
wrote:
> On 5/1/14, 7:30 AM, H. S. Teoh via Digitalmars-d wrote:
>> On Thu, May 01, 2014 at 01:37:28AM -0700, Jonathan M Davis via 
>> Digitalmars-d wrote:
>>> While it's not good to rely on finalizers, they're good to 
>>> have as
>>> backup if the appropriate cleanup function doesn't get called 
>>> like
>>> it's supposed to. They're not as critical as they'd be in 
>>> Java, since
>>> we have structs, but I'd be disinclined to remove finalizers 
>>> from D
>>> without a really good reason.
>> [...]
>>
>> I'd like to hear an enumeration of those reasons as well.
>
> 1. Most scarce resources must be released eagerly. GC 
> collections occur relatively rarely and are triggered by 
> different signals (low on memory).
>
> 2. The notion of running the GC when one runs out of file 
> handles or sockets is terribly inefficient.
>
> 3. Destructors are odd - they will run in a different thread 
> than the one that created the object. They also are limited in 
> surprising ways, i.e. may not allocate memory or block on other 
> threads directly or indirectly.
>
> 4. Due to imprecision, there's no actual guarantee any given 
> destructor will end up running. Leaving a scarce resources at 
> the whim of a best-effort approach is poor design.

These are good arguments against destructors for GC managed 
objects, IMO.

But conceptually, this is _not_ the same as classes! As others 
have mentioned, it's possible to created structs with `new`, or 
have them in dynamic arrays, as well as managing class objects 
manually.

Maybe the language should have some way to distinguish between 
GC-managed and manually-managed objects, preferably in the type 
system. Then it could be statically checked whether an object is 
supposed to be GC-managed, and consequentially shouldn't have a 
destructor.

The difference between classes and structs should then be 
reference vs. value semantics, and polymorphic vs static (which 
correlate nicely). It should, however, not imply whether the 
object is managed by the GC or not. Some kind of ownership 
mechanism would be more suited for that.