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 💥Change UnitAbbreviationsCache ctor to not load defaults #1476
• UnitParser.ctor(UnitAbbreviationsCache) should not fallback to built-in units if given null 💥Change UnitParser ctor to require unit abbreviations cache #1477
• 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)
  • Remove static Default getters pointing to UnitsNetSetup.Default 🔥Remove static Default getters, obsoleted by UnitsNetSetup #1475 reverted by Revert "🔥Remove static Default getters, obsoleted by UnitsNetSetup" #1480
• Fix typo in TonneSquareMilimeter, missing l
• Fix typo in VolumeConcentration.LitersPerMililiter, missing l VolumeConcentration: fix typo in LitersPerMililiter (missing 'l') #1497
• Remove TorquePerLength: dimensionless, domain specific, conflicts with Force = Torque / Length Removing TorquePerLength #1458
• Rename ThermalResistance to ThermalInsulance: enables future conversions between thermal conductivity, resistivity if added Rename ThermalResistance to ThermalInsulance #1460
• Change Angle base unit from Degree to Radian
• Fix typo KiloNewton => Kilonewton in SpecificFuelConsumption.json
• UnitParser: fix the nullability of the Parse / TryParse overloads #1445
• v6-Electric #1467
• 💥Remove obsolete electric quantities #1482
• PressureUnit: remove the MeterOfElevation and FootOfElevation #1531
• Consolidate UnitsNetSetup.Default.UnitConverter and each quantity's DefaultConversionFunctions, these can become inconsistent when adding custom conversion functions at runtime. Consider making DefaultConversionFunctions internal, not public.

[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]

@angularsen Are you ok with renaming the IArithmeticQuantity to IAffineQuantity or would you rather we keep it (mark it as obsolete)? For the other two interfaces I was thinking of INonAffineQuantity and ILogarithmicQuantity with the latter having an additional read-only property called LogarithmicScalingFactor (this could be static for net8.0, but for netstandard it would have to be non-static for the extensions to work). Also, I previously mentioned having a LogBase but I guess we could start with the base-10 assumption and extend it later if needed.

Oh, there is a good explanation (and a better naming IMO) here:

• Vector quantities may be added to each other, yielding a new vector quantity, and a vector quantity may be added to a suitable affine quantity (a vector space acts on an affine space), yielding a new affine quantity.
• Affine quantities cannot be added, but may be subtracted, yielding relative quantities which are vectors, and these relative differences may then be added to each other or to an affine quantity.

So, I guess the proper interface would be IVectorQuantity or IVectorialQuantity if we want to be fancy :)

[angularsen]

Great article! It perfectly captures the confusion we've had with Temperature in the past. The term affine is unfamiliar to me and I suspect to most people. I'm all for following well defined terms and concepts on this, but I also want to ensure the library stays easy to use and understand. Ideally, most people won't ever have to know about affine vs vectorial to be able to use our Temperature quantity correctly and intuitively.

Then again, most are not using the interfaces anyway since it's usually only relevant when dealing with quantities generically, so maybe it's not a big deal.

At first glance, IAffineQuantity and IVectorQuantity seems like good names based on the article, plus the ILogarithmicQuantity you proposed. Maybe IVectorialQuantity is a more consistent naming along with the other two though. Then again, in the article and on google it seems they mostly talk about "affine space" vs "vector space", not anything vectorial. 🤷

Are you ok with renaming the IArithmeticQuantity to IAffineQuantity or would you rather we keep it (mark it as obsolete)?

Let's avoid breaking changes where we can, keep it and mark it obsolete. We can remove it later, as long as it doesn't add too much friction for us in the meantime.

[angularsen]

Big fat release on the way out, merged in changes from master.
Previous release was Aug 23.

Release UnitsNet/6.0.0-pre013 · angularsen/UnitsNet

@lipchev

[Anthonywolfe]

With IQuantity implementing IParsable would it also be desirable to add support for IUtf8SpanParsable?

[lipchev]

With IQuantity implementing IParsable would it also be desirable to add support for IUtf8SpanParsable?

In the current implementation the QuantityParser, with its regex and all, is the worst performing class of the whole library. There are also potential problems that need fixing regarding the fall-back culture (see #1443 ), but given how slow we've been moving with the PR reviews lately, and how many of those I've got in the pipeline, I decided to leave it for another day.

That said, if you want to take a stab at it, I'll have a look- but please have a look at the direction I took in #1507, I think that would be a necessary first step towards a more performant implementation.

[Anthonywolfe]

In the current implementation the QuantityParser, with its regex and all, is the worst performing class of the whole library. There are also potential problems that need fixing regarding the fall-back culture (see #1443 ), but given how slow we've been moving with the PR reviews lately, and how many of those I've got in the pipeline, I decided to leave it for another day.

That said, if you want to take a stab at it, I'll have a look- but please have a look at the direction I took in #1507, I think that would be a necessary first step towards a more performant implementation.

Ah, I probably should of taken a closer look at how the QuantityParser was implemented before asking as I was hoping it would be a easier lift since I mostly wanted it to move/unify some generic parsing logic to all use IUtf8SpanParsable in my code base.

Still I'll run some profiling on my side of things and see if I can justify some time to put some work into optimizing the QuantityParser.