Define Destroy for class types

[cjdb]

Define the core interfaces Destructor, Destroy, TrivialDestroy, and DynamicDestroy. Describe how destroy works for class types.

[chandlerc]

I feel like the pair of terms here are a bit hard for me to read clearly. Mostly, I'm worried that a modifying word like "isolated" doesn't leave it clear that subobject destructors may not be trivial...

What do folks think about instead using two distinct terms here, "trivial" and something else for what here is "isolated trivial destruction"? My best initial idea is "simple destruction"?

[cjdb]

"Simple destruction" is decent, but I think the best solution would be to describe trivial destruction in an entirely different way. This paragraph has been one of the hardest to write, because of its recursive nature.

Types that do not implement Destructor have trivial destruction if, and only if, none of their subobjects implement Destructor.

That's the best I can come up with. Alternatively:

Types that do not implement Destructor have trivial destruction if, and only if, all of their subobjects have trivial destruction. Types that implement Destructor do not have trivial destruction.

Thoughts on these alternative phrasings?

[cjdb]

A type has trivial destruction if, and only if, neither it, nor any of its subobjects, implement Destructor.

A type has trivial destruction if, and only if, it does not implement Destructor and none of its subobjects implement Destructor.

I think I like this last one the best.

[chandlerc]

It's not clear why we need to do this given that we later make constraining on Destructor an error -- even without impl-ing it, the ability to impl it is still "reserved".

Is there another reason for this?

[cjdb]

I think this syntax implying that C1 has non-trivial destruction subtle, and that having something a bit more explicit would be helpful.

class C1 {
  impl as Destructor {
    fn Op(self) {}
  }
}

The best we can do without this would be

class C1 {
  impl as Destructor {
    fn Op(self) {
      // C1 has non-trivial destruction, but this destructor
      // is intentionally empty.
    }
  }
}

[chandlerc]

I think you need to explain a bit more here in order to bridge from #1154 and the current design's for destruction and your update here. Either here, or in an update to the design docs. For example -- how do these terms map to the very different terms currently in the design? What updates would happen to the design to integrate and connect it with these interfaces? How does it interact with the current design's destroy function?

[cjdb]

Would it be better to describe these in the proposal, or in the design doc?

[chandlerc]

A bit surprising that this is private -- can it not be called?

Should it be unsafe instead?

[cjdb]

Good catch. This should be final (per #6124).

@zygoloid doesn't mention unsafe, but the operation is unsafe. Was this omission intentional?

[chandlerc]

This in particular seems a bit odd to be private.

[cjdb]

Replaced with final. Same for TrivialDestroy.

[chandlerc]

I think there are a lot of design decisions here that we should probably have alternatives?

[cjdb]

I've pushed my most recent changes. Feel free to review values.md, but the proposal doc is not in a reviewable state yet.