Is trivial destruction expressable as a requirement?

[jonmeow]

Summary of issue:

While discussing partial and Destroy for #6161 (also related to #6124), virtual destruction was lightly touched on but mostly as a "we should file a question about it".

Here's the a few related design questions around trivial destruction:

1. Can code query whether a given type T trivially destructible?
   • Example use case: Does an array of T require per-element destruction (allowing cheap destruction of arrays of trivial types)?
2. Can a type T require that it (and any base types) are trivially destructible?
   • Example use case: Ensure that type T is trivially destructible so that it can take advantage of performance improvements from (1).
3. Can a type T require that children are trivially destructible?
   • Example use case: Create a family of types descended from T that all have the same performance characteristic.
   • In theory any API accepting the family of types could include trivial destructibility as a constraint if (1) is possible, although it'd be more verbose.

I'm hoping this captures the possible queries developers might want.

Details:

In the past, it's been discussed that something like a Destroy impl with an no-op fn Op might be "trivial" destruction. However, the implementation of fn Op is opaque and hard to condition on. Similarly an empty Destructor impl doesn't enforce any constraints on parents; and the existence of a Destructor impl at all probably means non-trivial destruction, just with no extra calls (actually preventing users from relying on trivial destruction). As a consequence, I think there are feasibility issues with conditioning trivial destruction on the contents of the definition of either Destroy.Op or Destructor.Op.

Regarding (3), zygoloid suggested a generic approach might be possible wherein a parent type says something like "all children must include a mixin, and this particular mixin says the child is trivially destructible". As a consequence, it may make sense to delay any answer on (3).

Any other information that you want to share?

Given a blanket impl of an empty TrivialDestroy interface (added using an approach similar to Destroy, discussed in #6124), I think (1) could look like impls TrivialDestroy and (2) could look like impl as TrivialDestroy {}.

As noted above, I think delaying any decision on (3) probably makes sense (perhaps only revisiting if there's a more concrete use-case, and there's still no answer).

Regarding diagnosing issues, I think the Destroy blanket impl (and DynamicDestroy) should still be generated for TrivialDestroy types, and could error in the case of (2) if there's an issue between expected trivia l destruction and actual trivial destruction (which would include an impl as Destructor). Per #6124 there's mention to behave as if "synthesizing an impl at the end of the class", so maybe that's enough? This might shift depending on what choices are made for an opt out "not destroyable" mechanism... I think the main goal should just be that it's diagnosed if a type impls TrivialDestroy and is not trivially destructible, without requiring an attempt to destroy it (i.e. it should error on type definition, not first use).

[nmsmith]

Folks might find it helpful to study how Mojo handles "trivial" types. In particular, I suggest looking at the "associated alias" __del__is_trivial_unsafe.

For context: Mojo's @parameter if is a compile-time branch that is eliminated during specialization.

[jonmeow]

The main thing I note from Mojo is the question of whether leads want types to be able to both implement the Destructor interface and be trivially destructible (i.e. destructor could be run, but is unsafe to run?). Generally I think discussion has assumed that implementing a Destructor means it must be run for valid code, meaning not trivially destructible. Similar for trivial copy vs implementing custom copy, or move.

My expectation would be that, baseline, DynamicDestroy and Destroy should both work to provide trivial implementations -- but as noted in the List example for Mojo, there could be surrounding logic (e.g. looping over members) that might not cleanly optimize away. So avoiding that loop would probably look like a specialization again, similar to what was trying to be avoided with the DynamicDestroy approach. Maybe that issue could be addressed generically by making it easier to provide specialized implementations of functions when an input type adds an extra interface? (which today, probably requires something like OptionalStorage)

This reminds me of another thought, versus impl as TrivialDestroy {}, syntax could also be require impls TrivialDestroy (adapting the syntax of constraint).