The `SupportsSIUnitSystem` property should no be needed

[lipchev]

You know how many of the quantities would throw an exception from their ToUnit/As(UnitSystem) method when they don't have any unit with a proper SI BaseUnit.. well I'd like to change that (at least in regards to UnitSystem.SI):

• I think it's reasonable to say that no matter what unit system we use, "a dimensionless quantity should have the decimal fraction as it's base unit" - with the %, ppm, ppb etc. being the derived units. In the future we could probably talk about extending our definition of the BaseUnits (e.g. consider mg/mg as [M][M^-1] or something) but as long as the ratio is composed of the same base-units (i.e. no additional conversion such as x * 100) we could simplify the code generated for these methods to ignore the parameter (the unit system) and simply return the As(BaseUnit).
• from memory, there are only a couple of other quantities which were failing (mostly due to simply missing their BaseUnits in the json-definition): I've already got these ready (as I needed them for something else)
• from memory, the only breaking change w.r.t. the existing definitions was the Angle which used to have the DegreeCelsius as it's BaseUnit (which we've already fixed) and the FuelEfficiency, which I wanted to invert (I don't remember where I mentioned this), and for which I had to add the "SI unit" (don't quote me on that ) MeterPerCubicMeter (m/m³) (we could go even further and say that this should probably be it's BaseUnit but I haven't gone that far..😆)

Overall, I know that this can be done (as I've already removed the SupportsSIUnitSystem from my version of the tests, a few months ago..), so if you don't mind I'd like to do it for the v6.

PS In the future (or whenever you say), I'd also like to move the As(UnitSystem) and the ToUnit(UnitSystem) methods out of the IQuantity interface (similarly to what I propose in #1461 w.r.t. the "Equals with tolerance", these could be transformed into extension methods, without breaking the existing usages).

PS2 There is of course a lot more work to be done regarding the support for the other unit systems but I think we can keep the experimental flag on these for the v6 release, and come back to it later (I do have some ideas on the matter)

PS3 Having merged most of the SI / BaseUnits related stuff here's a summary of what's left:

• ElectricApparentEnergy : see about adding an SI unit (VoltampereSecond, Joules?), if any of these make sense (CC @McNeight)
• ElectricReactiveEnergy: see about adding an SI unit (VoltampereReactiveSecond, Joules?), if any of these make sense (CC @McNeight)
• MassFlow: see about changing the BaseUnit to KilogramPerSecond : this was already mentioned in MassFlow base unit #1295
• TemperatureChangeRate: see about changing the BaseUnit to KelvinPerSecond : this would make it consistent with the Temperature (and make the operations a bit faster)
• ThermalInsulance: see about changing the BaseUnit to SquareMeterKelvinPerWatt
• FuelEfficienency: as decided in Changing the Dimensions and BaseUnit for the FuelEfficiency #1489, we won't be adding the MeterPerCubicMeter: all tests would be skipped / not generated at all (using the SupportsSIUnitSystem flag)
• RelativeHumidity: currently has only the Percent unit, I think we should add the DecimalFraction, setting it to be the BaseUnit (respecting the dimensionless quantity convention)

[lipchev]

You know how many of the quantities would throw an exception from their ToUnit/As(UnitSystem) method when they don't have any unit with a proper SI BaseUnit.. well I'd like to change that (at least in regards to UnitSystem.SI):

* I think it's reasonable to say that no matter what unit system we use, "a dimensionless quantity should have the decimal fraction as it's base unit" - with the `%`,  `ppm`, `ppb` etc. being the derived units. In the future we could probably talk about extending our definition of the `BaseUnits` (e.g. consider `mg/mg` as `[M][M^-1]` or something) but as long as the _ratio_ is composed of the same base-units (i.e. no additional conversion such as `x * 100`) we could simplify the code generated for these methods to ignore the parameter (the unit system) and simply return the `As(BaseUnit)`.

I almost forgot- with this proposal, I'd also like to remove the constructor that takes a UnitSystem from the dimensionless quantities:
public Ratio(double value, UnitSystem unitSystem)

[angularsen]

So in summary:

• Change Ratio to support SI unit system, and use decimal fraction as its SI unit
• Add BaseUnit for a few other quantities
• Add FuelEfficiency.MeterPerCubicMeter to be SI compatible, and optionally make it its base unit
• Move As(UnitSystem) and ToUnit(UnitSystem) out of IQuantity, make it an extension method instead (binary breaking change, source compatible)

I think this all sounds good, I'm fine doing this in v6 while you are on a roll.
Changing base unit should generally not be a huge breaking change, I consider it an internal implementation detail that external consumers should not rely on being permanent.

Regarding extension methods, make sure to put them in the UnitsNet namespace to be discoverable.
Also, I haven't thought through this, but we could maybe introduce ISiQuantity + ISiQuantityInfo interfaces for quantities that do have SI units, if it helps. Not sure what extra info I would expose at the top of my head though.

[lipchev]

So in summary:
* Move As(UnitSystem) and ToUnit(UnitSystem) out of IQuantity, make it an extension method instead (binary breaking change, source compatible)

Regarding extension methods, make sure to put them in the UnitsNet namespace to be discoverable. Also, I haven't thought through this, but we could maybe introduce ISiQuantity + ISiQuantityInfo interfaces for quantities that do have SI units, assuming there are quantities that simply don't have an SI unit.

We can do all but this part within the current v6, for the extension methods we'd have to wait for the Fractions/Unsafe version.

Even so, fixing the tests to work with the current interface definition would be quite helpful- it would at least remove (most) of the changes/merge conflicts we'd have in the tests (and improve the coverage- I already have the UnitSystem methods covered to 100%).

Furthermore, I won't even have to do all the changes to the UnitDefinitions in order for the potential PR to work- I've already made the relevant tests virtual, so I can just [Skip] the problematic quantities in the initial PR.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was automatically closed due to inactivity.