Skip to content

Conversation

@chiphogg
Copy link
Member

@chiphogg chiphogg commented Feb 6, 2026

Now that we have UnitSum<...> in place, it has become straightforward
to get the labels we want.

The trickiest bit here is when the constant fully cancels additively.
Recall that we are grouping inputs according to the unscaled units
(roughly corresponding to "actual unit symbols"). When every unscaled
unit additively cancels individually, the result is zero. When we end
up with multiple unscaled units which nevertheless cancel together, we
represent that as-is, and don't try to cancel it, because this is also
how we handle input units in multiplication and division. But the
result is still not-a-unit! And we have the static assert from the
parent.

From an external user's point of view, we simply recommend that they
not try to form any Constant that additively cancels, regardless of
whether it produces Zero or a compiler error. This is a weird thing
to do that probably doesn't have any actual use cases. We already don't
support all combinations of inputs, and don't plan to, and this feels
like a safe "starter policy" at the very least.

Fixes #607.

Now that we have `UnitSum<...>` in place, it has become straightforward
to get the labels we want.

The trickiest bit here is when the constant fully cancels additively.
Recall that we are grouping inputs according to the _unscaled_ units
(roughly corresponding to "actual unit symbols").  When every unscaled
unit additively cancels _individually_, the result is zero.  When we end
up with multiple unscaled units which nevertheless cancel together, we
represent that as-is, and don't try to cancel it, because this is also
how we handle input units in multiplication and division.  But the
result is still not-a-unit!  And we have the static assert from the
parent.

From an external user's point of view, we simply recommend that they
_not try to form_ any `Constant` that additively cancels, regardless of
whether it produces `Zero` or a compiler error.  This is a weird thing
to do that probably doesn't have any actual use cases.  We already don't
support all combinations of inputs, and don't plan to, and this feels
like a safe "starter policy" at the very least.

Fixes #607.
@chiphogg chiphogg merged commit cd25d11 into main Feb 6, 2026
27 checks passed
@chiphogg chiphogg deleted the chiphogg/add-sub-constant#607 branch February 6, 2026 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support arithmetic and comparison operators on Constants when safe

2 participants