UnitsNet: v5: Wishlist for breaking changes

Although there are no immediate plans to do a vNext, this issue serves as a wishlist/reminder of what to consider changing in case we need to bump the major version in the future.

To clarify

These are some things we should figure out before finalizing version 4.

A common denominator for design choices is binary size. The library was nearing the 1MB mark and the majority of that is the large number of methods and properties for all our 700+ units. In particular number extension methods add 8 methods per unit (!). With some clever hacks we brought this back to 600kB without any breaking changes, but we want to keep binary size in mind for any new changes we introduce.

TODO Clean up and organize this brain dump:

• Numeric type for value representation: Keep double? Switch to decimal? Offer both? Separate nugets? What about float?
• Base types: To make it easier working with quantities generically, accessing value and unit, get units and their abbreviations, parsing and ToString() without know the quantity type in advance.
• struct vs class: Weigh all the pros and cons, performance (stack vs heap), inheritance vs interface
  • class: Can support all number types (float, double, decimal) without increasing binary size N times (discussion)
  • struct: More suitable for performance and memory constrained applications (what is the impact in practice?), avoids pressure on garbage collector, quantities match the semantics of being a value type

List of breaking changes to make

Removing things

• https://github.com/anjdreas/UnitsNet/commit/7a455f0c12f5beed3790a7f5a1f6a65055f13c32: Remove default Temperature arithmetic, it is not correct (made this breaking change already, due to existing behavior not being correct).
• Remove UnitClass type, replaced by QuantityType
• Remove nullable From factory methods causing N additional methods for N units, see comment
• Remove == != and Equals(object) and Equals<T>(T) since they don’t take a max error argument and is prone to floating point rounding issues, instead users should use Equals() methods that take a max error argument
• Remove code marked as [Obsolete], such as Volume.Teaspoon unit that was too ambiguous
• Remove static methods on UnitSystem, should use UnitSystem.Default instead
• Remove unnecessary overloads on number types (8 overloads for each of the 700+ units) #372

Changing behavior

• Throw exception on NaN values in unit class constructor methods (#176)
• Throw if unit was not specified when constructing quantities https://github.com/angularsen/UnitsNet/pull/389#issuecomment-362811310
• Stricter parsing (see #343 and https://github.com/angularsen/UnitsNet/issues/180#issuecomment-357100824)

Renaming

• Acceleration units missing plural s in Meters (fixed in #434)
• Correct SingularName for some Flow unit definitions (see #360)

Fixing

• Search for any TODO comments in the code to address, remove comment and either fix or create issue