How does `partial` interact with destruction?

[jonmeow]

Summary of issue:

Followup to #6124

The decision on #6124 was that abstract types do not impl Destroy. Does a partial abstract type impl Destroy?

Details:

Carbon's generally expecting people to write factory functions for parents, and those factory functions will often return partial Self for a base class. Particularly for an abstract type, where they must return partial Self.

A factory function's return type could also be something allowing failures, such as Optional(Self) or Self*?. The timing of when failure is allowed is important.

1. partial types impl Destroy as long as their object representation does: If failure after construction starts but before it completes is to be allowed (including something like a parent type partially constructing, but a child type failing to construct), then I think a partial abstract type must be able to Destroy, in order to garbage collect the partially destructed state.

   • It would be a particular concern if a partial type could not impl Destructor, because of potential leaks. See below for further notes on this.

   • It may be worth thinking about how this interacts with the theorized Indestructible interface -- do people do impl partial T as Indestructible to mean that both T and partial T can't be Destroyed (because partial T is inherently part of T's representation), or does impl T as Indestructible imply that partial T also can't be Destroyed (just always doing the impl lookup removing partial)?

2. partial types do not impl Destroy: it could be a language rule that once construction of partial state starts, the end result must be a complete object, and only the completed object can be destroyed.

   • Factory functions would need to rely on returned var move semantics and only starting construction of base types after they're sure construction will succeed.

3. partial types only impl Destroy when the main type impls Destroy: This is subtly different from option (1) in that it means a partial abstract type does not impl Destroy, but a partial base type does.

   • This is noted in part for the question of Indestructible on (1) -- it's an approach that makes the partial version consistent.

Any other information that you want to share?

Regarding partial and Destructor, #6124 decided the signature of Destructor is:

class B {
  impl as Destructor {
    fn Op[ref self: Self]() { ... }
  }
}

As long as I'm asking questions about partial types, I'd like to confirm that this decision -- that destructors can only be called on non-partial types -- holds. Note destruction order probably looks something like:

1. Call Destructor for child type
2. Destroy members of child type
3. Call Destructor for parent type
4. Destroy members of parent type

Since Destructor takes a non-partial Self, it means that the parent destructor can continue to use virtual functions.

Note though that using Destructor with partial Self also implies the signature would be more like:

class B {
  impl partial Self as Destructor {
    fn Op[ref self: Self]() { ... }
  }
}

(where Self there changes from B in Destructor to partial B in Op)

or a different interface; perhaps:

interface Destructor {
  private fn Op[ref self: partial Self]() { ... }
}

Maybe #6124 should be augmented adding partial to the Destructor interface?

[jonmeow]

My own leaning would be that partial T impls Destroy for abstract types, and that Destructor.Op takes partial Self instead of Self.

The latter should give reliable behavior for virtual functions that is consistent with decisions around partial. And if Destructor.Op takes partial Self, then Destroy for a partial T should be defined behavior since it's how Destroy would normally unwind types, it's just that sometimes it would be run on a type that never ended up used for a non-partial type.

That said, I also want to note that supporting Destroy for a partial abstract type was bothering @josh11b and @dwblaikie. So (2) at gives a a consistent philosophy down that route (developers can't start a construction that can't be finished), although it may still make sense to have Destructor.Op to take a partial Self to prevent calling virtual functions affecting children where Destructor has already been applied.

[jonmeow]

Thinking further, due to final classes needing impl as Destructor to be non-partial, I think options are:

1. impl as Destructor needs to be written as impl partial Self as Destructor
2. There should to be two different interfaces -- one for final classes, one for classes with partial types.
3. There should be three interfaces -- one that can destruct T, one that can destruct partial T (abstract), and one that can destruct both (base).

In particular, I think given the code:

abstract class C {}
base class B { extend base: C; }
class A { extend base: B; }

Destroying an instance of A could call Destructor.Op for:

1. A
2. partial B
3. partial C

Destroying an instance of B could use the destructor for B, partial B, or both -- my own suggestion would be both.