Mark format::Numeric and format::Fixed as non_exhaustive

[pitdicker]

One thing that makes improving our parsing and formatting code difficult is that adding new formatting items is a breaking change.

Almost all formatting items live in format::Numeric and format::Fixed enums within a format::Item.

User code matching on the these enums within a format::Item is very rare. When we did add variants to it in 0.4.23 it broke one abandoned crate (see #899, #1151).

format::Pad could also benefit from becoming non_exhaustive, but there is a slightly higher chance people are exhaustively matching on its three variants.

For 0.5 we should mark these enums as non_exhaustive. And given the low impact of the accidental previous change we may consider it on 0.4.x.

[djc]

Definitely sounds good to me for 0.5. For 0.4, what's the compatibility calculus here?

[pitdicker]

For 0.4, what's the compatibility calculus here?

That's a new term for me...

Two arguments:

• Why would users want to exhaustively match on format::Numeric or format::Fixed?

  • Pretty much only when they want to reuse for strftime parser with their own implementation of formatting or parsing.
  • If they want to check if a strftime string includes / does not include some fields they might match on these items, or they may do a regex on the input string.

  Both seem to be rare (and easily fixed, although that doesn't make breakage good).

• We had a kind of crater check on this near the end of 2022 when adding variants to it broke one crate.

[djc]

We had a kind of crater check on this near the end of 2022 when adding variants to it broke one crate.

Okay, and I assume it was a niche/obscure one? Sounds good to me, let's do it (and make sure to note it in the release notes).

[pitdicker]

Okay, and I assume it was a niche/obscure one?

It was chrono_locale, which has 13.252 all-time downloads, not seen an update for 5 years, and only one dependent crate (seemingly a hobby project).

[djc]

Yes, that doesn't seem like a blocker.