Review

This is a clean, well-scoped removal PR. Summary of findings below.

Breaking changes

Correctly flagged in the PR description. This removes public API: Scalar, ScalarUnit.Amount, Scalar.FromAmount(...), .Amount property, parsing/formatting APIs, and the 2.Amount() / 2.Amount number extensions. This is a major-version-worthy breaking change and should land with a corresponding entry in the next major version's release/upgrade notes (per Docs/README.md#upgrade-guides) so downstream consumers relying on Scalar have a documented migration path (e.g., "use double/decimal/QuantityValue, or Ratio for dimensionless physical relationships," as stated in the PR description).

Alignment with project criteria

This removal is well justified by .agents/criteria-for-adding-quantities-and-units.md, which explicitly states a quantity should not be "dimensionless/unitless (consider using Ratio)." Scalar violates this outright, and grepping the generated code confirms it never appears in any cross-quantity relation (e.g. IDivisionOperators<Scalar, X, Y> for other X/Y), unlike quantities such as Length which participate in many. So the "no meaningful semantic usage" claim in the motivation checks out.

Completeness of the removal

I verified via rg -n "\bScalar\b" across the whole repo (working tree already reflects the merge) that there are no dangling references left in docs, README, CHANGELOG, or code — the removal is thorough:

• Common/UnitDefinitions/Scalar.json deleted, and the corresponding Scalar entry removed from Common/UnitEnumValues.g.json.
• All 5 generated artifacts removed (quantity, unit enum, resource file, number extensions x2 including the CS14 preview variant, and their generated tests).
• Aggregate registration lists correctly pruned: Quantity.g.cs (DefaultProvider quantity list and RegisterUnitConversions), IQuantityTests.g.cs (both the unit-assertion list and the QuantityInfo_IsSameAsStaticInfoProperty list).
• Hand-written UnitsNet.Tests/CustomCode/ScalarTests.cs (subclass of the generated ScalarTestsBase) is also removed, since its base class no longer exists.

This is exactly the kind of change that's easy to leave half-done (e.g. forgetting an aggregate list entry), but everything here appears consistent — nothing suggests a generator or template change, just data + regenerated output.

No generator changes

There are no changes to CodeGen/Generators/, so this doesn't touch the "how" of code generation — only the "what" (the Scalar.json definition input is gone, so the generator's normal aggregate-list logic naturally stops emitting Scalar entries). Nothing to flag on generator correctness.

Nit

Minor, non-blocking: the PR body's validation section says "Refs #849, #1200, #1679" — worth double-checking #1200 is actually relevant to this change (vs. #849 and #1679 which are directly referenced in the motivation) so reviewers/future readers aren't sent on a wild goose chase.

Overall: solid, well-motivated removal with good hygiene. My main ask is just to make sure the breaking change is captured in upgrade/migration docs before release.

@Muximize @lipchev Would like a second opinion here.

Scalar is largely unused in our code base, and as discussed in #1679 (review) I don't believe Scalar is an improvement over double in the UnitsNet API for scalar results.

I'd rather move towards QuantityValue as part of #1544 if it helps improve precision beyond what double can do.

However, looking at the original motivation for adding Scalar #849, I can see some minor convenience in offering it and it may just cause more harm removing it than keeping it.

Thoughts?

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96%. Comparing base (a7443cf) to head (6cd1891).
⚠️ Report is 86 commits behind head on master.

@@          Coverage Diff           @@
##           master   #1680   +/-   ##
======================================
  Coverage      96%     96%           
======================================
  Files         450     447    -3     
  Lines       29306   29207   -99     
======================================
- Hits        28271   28189   -82     
+ Misses       1035    1018   -17     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

I've read the motivations in #849 and I don't find them very convincing.

I have a property of type IQuantity

But if the value is not always a quantity, why was that type chosen? It looks like a design problem in that framework which was worked around by adding a misfeature to UnitsNet.

I'm in favor of removing Scalar, also to avoid confusion about whether to use it where double etc. would suffice (I guess I was a victim of that in #1679 😅).

Thanks, yes I also lean towards removing it because it semantically isn't a quantity and adds confusion rather than value.
Also, anyone can just implement their own Scalar if actually needed.

Another use case for Scalar: #1678

I use Scalar and would have issues if it disappears
i have types with a quantity column, the quantity can be any type, feet, inches, gallons, pounds, etc.
but it can also be "Each" or count.
i.e.

• 3ft of wire - Length
• 1 oz glue - Mass
• 3 (EA) wire lugs - Scalar

without the scalar type, this property can no longer be a units net IQuantity as it is now, as I will have to revert to having untyped data, or reimplement the Scalar myself.

this pattern is common in Bill of Material scenarios.
i think there has been no usage of the type in unitsnet code because its a simple guy, its only purpose is like the above and it requires no modifications otherwise.

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