Non-exhaustiveness and runtime validations

[cijothomas]

Discussed in #2499

^{Originally posted by psandana January 7, 2025}
On #2228, a lot of structs and enums gained the non-exhaustive attribute, making them forward compatible with future additions of new fields. This is convenient to allow otherwise breaking changes.

But this benefit comes with the cost of forcing users to add a _ match arm, that will capture any new value they were not designed to handle. This is similar to the default match arm in other languages like C++. Historically, this has been the source of many runtime issues, as assumptions of today may not be sustained in the future causing logical errors difficult to debug and fix.

One of the advantage of staying "exhaustive" is to rely on Rust compile-time checks, thus preventing the runtime issues. Despite losing the ability to introduce otherwise breaking changes, I would like to raise correctness as a principle over backward compatibility. This is not a proposal for all current non-exhaustive types. There are things that inherently are monotonically growing, like a list of supported types, and it is fine to have them non_exhaustive.

Particularly, I'm worried about the following which I think we shouldn't expect changes:

• Things that should not change, otherwise they should be renamed:
  • KeyValue
• Unit-type (changing from unit-type, to tuple or struct should still be a breaking change):
  • Key
  • StringValue
• Things that should not accept new types without breaking changes (here we risk to silently lose telemetry data, which may be dangerous):
  • Value
  • Array

I'm initiating this discussion to consider the removal of the non-exhaustive attribute from the above mentioned types.