[Dlang-study] [lifetime] Initial thoughts on lifetime management

[Jonathan M Davis]

On Tuesday, October 27, 2015 20:45:00 Andrei Alexandrescu wrote:
> * do not inherit Object. (Do we want a root of all @rc classes called
> RCObject?)

Honestly, I think that having Object was a mistake. We already decided
previously that we wanted to remove pretty much all of the functions from
Object in order to fix the problem with have with forcing specific
attributes on functions like toString or opEquals (though unfortunately, we
haven't gotten very far with actually implementing such changes). And if we
do that, Object becomes borderline useless. Also, because we have proper
templates rather than Java-style generics, we've eliminated what's probably
the primary use case for having an Object reference rather than the
reference of the actual type of the object (or one of its base classes whose
API actually gets used as opposed to just storing it as a reference toa base
type).

That being the case, I see no reason to have an RCObject. It's just
repeating our past mistakes.

> * cannot be converted to interfaces (we may later add @rc interfaces)

That seems like a potentially painful limitation, though I can see why it
would be necessary. I'd expect it to be pretty much a forgeone conclusion
that we're going to want to add @rc interfaces later, particularly when you
consider that at least a portion of the D community will inevitably switch
to using ref-counted classes and avoiding GC classes as much as possible.

> * have a vptr only if they define non-final methods (in particular, I
> think we should disable "synchronized" for them - it seems an
> unnecessary complication at least for v1)

Seems reasonable.

> * should they have a hidden pointer to the parent scope if nested?

I'm afraid that I don't follow what you mean by this - though we already
have problems with templated code not compiling due to there being two or
more scopes involved, forcing us to do stuff like make a voldemort type
static in case the predicate has an associated scope. So, I'd be leery of
adding more scopes along those lines if we don't have to (though I don't
know if that really relates to what you're talking about).

> So my plan is to start maximally conservative - i.e. bump the reference
> count appropriately for every use of the object. Then, we define a
> static analysis that eliminates or fuses together most of these
> increments and decrements. There is much research in this area. I am
> counting on the folks in this group to define this analysis rigorously.

Sounds like a plan.

- Jonathan M Davis