Consider the feasibility of an alternate design to the enum "raw"/"value" pattern.

[jrgerber]

This library has a design which acts as a mitigation for when the library detects a value which is unknown according to the current spec. For example an enumeration of size byte has 100 known values in it, a value of 101 is found. Either 101 is bad data or it is a valid value under a newer version of the standard (the library hasn't been updated yet).

The current design is to require enums have a value of "None" and set the value to "None" when an unknown value is received. The consumer can check the "raw" value to see what the unexpected value is.

During the 3.5.0 changes, a new problem arose for SMBIOS strings because the standard now is to read strings as UTF-8. However not all values are valid with UTF-8. Therefore, refactoring of strings to return Result<,> and bubbling up errors containing the original (raw) data is the solution. A similar strategy could replace the current enum raw/value pattern where Result is used instead of Option and the raw value is bubbled up in an Error. This assumes that the only time you need the raw value is when the value does not map to an enum value. Should there be a case where someone needs backing numeric values to an enum a helper function would be created.

[jrgerber]

Asking what the benefit would be of changing the design requires evaluating the difference between library consumer experiences in each design.

In the current design the consumer must identify the None match arm and then know they should look at the raw value to learn more.

In this alternate design they would have an error match arm containing the raw value. The consumer clearly knows this is a case of some type of exception and that the data within the error contains the details of why. Think this weighs in favor of the alternate design.

Negatives?