Should `Destroy` use a blanket impl for `class` types, or should it be instantiated per-`class`?

[jonmeow]

Summary of issue:

How should Destroy work for classes?

The two main options are:

1. Have a blanket impl next to Destroy which covers all classes that should support Destroy.
2. Generate an impl as Destroy as part of each class definition.
   • This would likely behave similarly as if users wrote that inside the class definition, particularly to support class C { class Nested {} var n: Nested; }

Details:

At present, we already expect to have blanket impls for other types implementing Destroy. For example: tuples, structs, arrays, T*, const T, and MaybeUnformed(T).

class is slightly different because classes are expected to have custom destroy functions, and have a definition owned by a specific library (in contrast with tuples).

There was significant discussion about what users should see, and what limits were desired, in the toolchain meeting on Sep 23.

Prior to the meeting, zygoloid and I had also discussed possible performance differences:

• In a blanket impl approach, one impl is imported for all types. Each type gets its own specific. Impl lookup would need to test against the blanket impl on the first lookup, but could in theory cache results (not yet implemented).
• In a per-class approach, there many impls, and each is imported separately. However, in theory impl lookup can look at only the impl that applies (though it may still need to examine and rule out blanket impls).

The discussion about performance was set aside since it didn't seem as compelling about the discussion about desired behavior.

[zygoloid]

Discussed by myself, @josh11b, @chandlerc -- see the discussion for more details. Leads decisions:

There are two main interfaces that together are responsible for destroying objects.

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

Destructor describes how to do custom cleanup and resource deallocation for that type. This does not include destruction of subobjects or lifetime management. It is only implemented by types with custom destructor logic; the lack of an impl of destructor implies that that class in isolation has trivial destruction (but its subobjects might still have nontrivial operations on destruction).

interface Destroy {
  final fn Op[ref self: Self]() = <some builtin>;
}

Destroy destroys complete objects, ending their lifetimes. The Op function operates as if by enumerating the subobjects that implement Destructor in a suitable order, then running the Destructor.Op function on each of them in turn.

// A does not impl Destructor, and therefore A in isolation has trivial destruction.
// A does impl Destroy, and that impl calls `self.n.(Destructor.Op)()`.
class A {
  var n:  str_buf;
}
// B has custom destructor logic. The impl of `Destroy` for `B` calls the
// destructor function for `B`.
class B {
  impl as Destructor {
    fn Op[ref self: Self]() { ... }
  }
}

There is no fn destroy or other special syntax in the class definition, beyond the affordances that we're working towards for single-function interfaces. A type that has custom destructor logic defines an impl of Core.Destructor. There might be a keyword dtor that names Core.Destructor, but the exact design here hinges on how we design the syntax for impling a single-function interface, which we consider non-blocking for the purpose of this issue. For now, we can use fully elaborated impl syntax under the assumption that a shorthand will be added later.

There is no mechanism to customize the behavior of Destroy. However, it is not implemented for all types. In particular, if a type is abstract, it should not implement Destroy, and also there should be an opt-out mechanism for types that are indestructible. If a type wants to be destroyable but wants to customize how its subobjects are destroyed, the mechanism for doing so is to use a raw storage type for the subobjects.

We want the behavior of Destroy to be as if there is a blanket impl for all destroyable types -- in particular, we don't want a "snapshot at the end of the class" model here, and it should be OK if the impl is added later in the library. (This isn't so important for Destroy but we want to use the same approach for things like Copy where there may be dependency cycles between classes in the same library.) If this behavior is instead obtained by synthesizing an impl at the end of the class, and deferring generating the Destroy.Op function until later, that's fine too, since that shouldn't be observably different. Either way, the impl should only be available for destroyable types, excluding abstract types. There should also be an opt-out mechanism, though the details of how that works are still open. (For example, an interface Indestructible that types could implement would be a potential option.)

[jonmeow]

To be sure I'm interpreting correctly:

1. "the lack of an impl of destructor implies that that class in isolation has trivial destruction"

IIUC, since code won't have an impls signal for trivial destruction (as discussed in notes), code is not allowed to rely on trivial destruction.

(e.g., var x: i32 will likely emit a destructor call in SemIR, although we might avoid a function call in lowering)

2. "if a type is abstract, it should not implement Destroy"

IIUC, this means that the object representation of a type which inherits from an abstract type is not destructible, because it includes the base (abstract) type.

Instead, we'll need a separate mechanism for determining whether the child type is destructible which special-cases abstract base types, and also to figure out some method for sharing Destroy logic which doesn't involved calling the base type's Destroy implementation.

3. While Destructor.Op is private, Destroy.Op is public.

IIUC, this means that fn F(x: C*) { x->(Destroy.Op)(); } is valid, but will likely leak memory.

[zygoloid]

1. "the lack of an impl of destructor implies that that class in isolation has trivial destruction"

IIUC, since code won't have an impls signal for trivial destruction (as discussed in notes), code is not allowed to rely on trivial destruction.

As a general point, we want to avoid using the term "destruction" as it's ambiguous between destructors (which just operate at one level within an object) and destroying an object (and its subobject).

We thought it would be reasonable to provide a TrivialDestroy interface, that is implemented automatically (and only) for types for which the list of subobjects with destructors is empty, and for code to depend on that. But depending on a trivial destructor is not something we'd want code to do.

2. "if a type is abstract, it should not implement Destroy"

IIUC, this means that the object representation of a type which inherits from an abstract type is not destructible, because it includes the base (abstract) type.

Whether a type can be destroyed depends on (potentially among other things) whether the type is abstract, and calls the destructor implementations for subobjects (which the abstract base can have despite not being destroyable). The destroy implementation for the derived class doesn't call the destroy implementation for the base class, it calls the base class destructor.

3. While Destructor.Op is private, Destroy.Op is public.

IIUC, this means that fn F(x: C*) { x->(Destroy.Op)(); } is valid, but will likely leak memory.

Yes, that sounds right to me (modulo the effects being properly annotated in safe Carbon). This would be analogous to

void F(C *x) { x->~C(); }

in C++.

[josh11b]

Would abstract types with a virtual destructor implement Destroy?

[zygoloid]

Would abstract types with a virtual destructor implement Destroy?

Presumably yes, but we still need to figure out how to fit virtual destructors into this model. I would expect the Destroy impl for the static type would internally do a virtual dispatch to run the appropriate Destroy impl in the derived class, but we also need some machinery to add the vtable entry for that, and to enforce that all non-abstract derived classes are destroyable and populate that vtable entry.

[jonmeow]

Per discussion, chandlerc agreed with what's written here.