v6 Wishlist

[angularsen]

This issue serves as a place to discuss what to include in this version, since major version bumps allow us to make breaking changes we think are necessary or worth it.

The wishlist keeps track of the items to include, but items may be added or removed at any time.

As changes are completed, they are added to https://github.com/angularsen/UnitsNet/wiki/Upgrading-from-5.x-to-6.x

Wishlist

• Remove BtuPerSquareFootDegreeFahrenheit Remove obsolete units #1372
• Fix plural form of Speed.MeterPerMinute
• Rename/fix calorie/btu units to specify their definition as International Steam Table (IT) or Thermochemical (th), see https://github.com/angularsen/UnitsNet/pull/1196/files#r1105112205
• Consistent imperial/UK/US unit namings v6 Wishlist #1200 (comment)
• UnitAbbreviationsCache.ctor() should create empty cache, not load default abbreviations
• UnitParser.ctor(UnitAbbreviationsCache) should not fallback to built-in units if given null
• Rename AbsorbedDoseOfIonizingRadiation to RadiationAbsorbedDose Add radiation equivalent dose #1352 (comment)
• Review all [Obsolete] in code and add to this list
  • Remove obsolete Equals overloads 🐛ComparisonType ignored in obsolete Equals method #1396 (comment)

[maxreb]

Add System.Text.Json support #966

[angularsen]

Decide on a naming and abbreviation convention for imperial/UK units and US units; like gallon, ounces, cup etc.

It is a bit of a mess right now:

LINQPad sample

void ListUnits(string withPartialName)
{
    Quantity.Infos
        .SelectMany(i => i.UnitInfos
            .Where(n => n.Name.Contains(withPartialName))
            .Select(u => new 
            { 
                u.Name, 
                Abbrev = UnitAbbreviationsCache.Default.GetDefaultAbbreviation(u.Value.GetType(), Convert.ToInt32(u.Value)) 
            }))
        .Dump(withPartialName);
}

ListUnits("Uk");
ListUnits("Imperial");
ListUnits("Us");

I personally like "UK", since it is shorter and better matches "US".
Wolfram also uses US gallon and UK gallon.

Some conventions for imperial gallons:
https://en.wikipedia.org/wiki/Gallon#:~:text=the%20imperial%20gallon%20(imp%20gal,American%20and%20Caribbean%20countries%3B%20and

Today the abbreviation convention is gal (U.S.) and gal (imp.).
Depending on landing on UK or imperial naming, we could go with one of these pairs:

• US gal and UK gal
• US gal and imp gal
• gal (US) and gal (UK)

We can support multiple of these plus the old ones, but the primary form should be standardized across the different units.

[ebfortin]

Do not throw ArgumentException on NaN, Inf+ or Inf- or give a way to configure the behavior globally.

Context:
#1268 (comment)

[MisinformedDNA]

I think UnitsNet should be more extensible. Perhaps there could be a base package, but separate NuGet packages for US measurements, Imperial, UK, etc. Alternatively, customizable abbreviations could be a solution. I would never expect me or my users to see "gal (US)" instead of "gal". This would also help the debate here.

UPDATE:

Custom abbreviations already exist: UnitAbbreviationsCache.Default.MapUnitToDefaultAbbreviation(HowMuchUnit.Some, "sm");

[angularsen]

I think UnitsNet should be more extensible.

Conceptually, I agree.

Customizable abbreviations is already supported as you found, and we support custom quantities and units with some limited functionality: https://github.com/angularsen/UnitsNet/wiki/Extending-with-Custom-Units

Splitting up in packages is not so easy though. Things like Torque = Force * Length becomes problematic when types exist in different packages and they can't have circular dependencies. Imperial is even worse, splitting some units of a quantity to different packages. The main problem is static typing, which is also one of the main features of UnitsNet.

One benefit of splitting up in packages is smaller binary size to only bring in what you need.
Some prototyping here: #1181

[Markussp256]

I was requested to give a list of units with the wrong plural form (see #1330 )

I checked the .json-file with the speed units and only MetersPerMinute has a wrong plural form, all other Speed units seem to have the correct plural form.

[angularsen]

@Markussp256

I was requested to give a list of units with the wrong plural form (see #1330 )

I checked the .json-file with the speed units and only MetersPerMinute has a wrong plural form, all other Speed units seem to have the correct plural form.

Some more fixes were made recently in
#1351

[lipchev]

MassMomentOfInertia.json has the unit TonneSquareMilimeter (with as single "l")

PS I'm surprised this is the only one- I often miss the second "l" as well.. Should I we add it for v6?

[lipchev]

In #721 it was (I think correctly) suggested that the ThermalResistance.json should be renamed to ThermalInsulance, what do you think about it? That would open up the "name" for the actual quantity (which I think was never added just because of the naming collision). There looks to be a nice triangle of relations that could be formed between these (also there are also the Thermal Conductivity/Resistivity etc..).

[lipchev]

Finally, I think we should change the BaseUnit of the Angle from Degrees to Radians (as per the SI definition), but more importantly, since SI doesn't have a base dimension for the Angle it relies on the fact that:

the SI radian is a dimensionless unit equal to 1. In SI 2019, the SI radian is defined accordingly as 1 rad = 1.

This is similar to how the Ratio or the MassFraction have their BaseUnit to the DecimalFraction (i.e. the "unit-less 1").

This would enable (and speed up) the "generic-conversions" with all other Rotational quantities (which are all based on the Radian).

[lipchev]

Ok, one more: what do you think about removing the TorquePerLength (added in #712 ) - I've been looking for half an hour already, and cannot find a single reference to any of it's units on the internet. The only document that was found using the XmlDocSummary:

"The magnitude of torque per unit length."

Was found on this page, where they say that

The torque coefficient is a dimensionless physical quantity that represents the magnitude of torque per unit length.

And down below there's a table with unit-less values.
Finally, there it isn't even possible to have a Torque / Length operator, as it is already taken (resulting in Force).

@dschuermans Is this quantity still useful to you? Do you think this is actually used by anyone else?