Revert IQuantity.UnitInfo DIM, expose GetUnitInfo() extension on all TFMs

[angularsen]

Summary

Reverts the default interface members added in #1649 and exposes GetUnitInfo() as extension methods on all target frameworks instead. The typed overload returns the most specific UnitInfo<TQuantity, TUnit> when overload resolution can infer both type parameters from the receiver.

Rationale

Per @lipchev's review feedback on #1649:

• Lean interface. The DIM is just a getter over QuantityInfo[UnitKey] — no new state, sets a precedent for further interface bloat (Dimensions etc.).
• Semantic trap. A custom IQuantity implementor overriding UnitInfo would silently diverge from internal lookups (UnitConverter, UnitAbbreviationsCache, QuantityFormatter) which all go through QuantityInfo, not the new property.
• Boxing on structs. Calling Mass.Zero.UnitInfo through IQuantity on a struct quantity boxes the receiver per call; concrete quantities don't override the property so the DIM path is the only one available.

The extension method gives the same call-site ergonomics (quantity.GetUnitInfo()) on every TFM with none of these issues.

Overload resolution

Caller has	Resolved overload	Return type
Length q;	GetUnitInfo<TQuantity, TUnit>(IQuantity<TQuantity, TUnit>)	UnitInfo<Length, LengthUnit>
IQuantity q;	GetUnitInfo(IQuantity)	UnitInfo
IQuantity<TUnit> q;	GetUnitInfo(IQuantity) (fallback)	UnitInfo

The IQuantity<TUnit> reference case loses its typed return — IQuantity<TUnit> does not satisfy the IQuantity<TQuantity, TUnit> constraint, so resolution falls back to the non-generic overload. That scenario is uncommon compared to the concretely-typed receiver case, which is now strictly better than before (returns UnitInfo<TQuantity, TUnit> instead of UnitInfo<TUnit>).

Follow-up

PR #1658 stacks on top of this branch: adds static abstract Info on IQuantityOfType<T> / IQuantity<TSelf, TUnitType>, obsoletes the instance QuantityInfo member, and provides matching GetQuantityInfo() extensions. Out of scope for this PR.

🤖 Generated with Claude Code

[claude]

Code Review — PR #1657: Revert IQuantity.UnitInfo DIM, expose GetUnitInfo() extension on all TFMs

Overview

This PR reverts the default interface member IQuantity.UnitInfo added in #1649 and instead makes GetUnitInfo() / GetUnitInfo<TUnit>() extension methods available on all TFMs by dropping the #if !NET guard. Net result: −26 lines, simpler cross-TFM API.

---

Breaking Changes

IQuantity.UnitInfo and IQuantity<TUnitType>.UnitInfo are removed. Any caller on an IQuantity reference needs to migrate:

// before
UnitInfo info = quantity.UnitInfo;

// after
UnitInfo info = quantity.GetUnitInfo();

Since UnitInfo was only added in #1649 (very recently), the blast radius should be small in practice. Still worth a clear note in the changelog/release notes.

---

Rationale — Agreed

The three reasons given in the PR description are all solid:

1. Lean interface — the DIM was just QuantityInfo[UnitKey], no new capability.
2. Semantic trap — a custom IQuantity implementor overriding the DIM would silently diverge from UnitConverter, UnitAbbreviationsCache, etc., which all use QuantityInfo directly. No compile-time signal of the inconsistency.
3. Boxing cost on structs — interface dispatch boxes the receiver; since concrete quantities don't (and can't) override a DIM, every Mass.Zero.UnitInfo-via-IQuantity would box.

---

Code Quality

• Clean diff. 8 additions / 34 deletions; the remaining #if NET guards in IQuantity.cs (for QuantityInfo IQuantity.QuantityInfo, Enum IQuantity.Unit) are untouched and correct.
• Stale XML docs removed. The <remarks> saying "On .NET 5+ targets, available as a DIM instead" in QuantityExtensions.cs are correctly stripped.
• No orphaned usages. Verified via grep — no remaining quantity.UnitInfo calls on IQuantity references in the codebase.
• Test renames follow the project's naming convention (GetUnitInfo_ReturnsUnitInfoForQuantityUnit, etc.) and the assertions are identical to before.

---

Minor Notes

• The Get prefix on GetUnitInfo() is slightly inconsistent with other extensions like As() and ToUnit(), but it makes sense here: it signals a dictionary lookup rather than a trivial property access, and mirrors GetHashCode() / GetType() precedent for non-trivial accessors.
• The follow-up described in the PR (static abstract Info on IQuantityOfType<TQuantity>) is a good direction; having it scoped out explicitly keeps this PR focused.

---

Summary

This is a well-reasoned, minimal revert. The rationale is convincing and the implementation is clean. LGTM once the breaking change is noted in the release notes.

[lipchev]

@angularsen This is surely better than having them on the interface, but here are my thoughts:

• the generic version uses IQuantity<TUnit> resulting in boxing when used with something like Mass.Zero (while still producing TUnit-number of concrete implementations)
• I haven't tested it, but I'm pretty sure both extension members would show up in the Mass.Zero. auto-completion list
• We could potentially ship these (and others like them) in separate nuggets, like the number extensions- using something like 'CSharp14' as a suffix where they could live as regular extension properties (note, I'm 99% certain, those can still target netstandard2.0)

Bottom line- I don't mind the addition, but if I were to ever need to use one of these properties in my own projects- I'd probably write my own extension block.

[angularsen]

Autocomplete shows both in Rider, but I think that is fine:

It favors the typed one:

Regarding boxing, this only applies when calling Mass.Zero.GetUnitInfo(), and this is not something I expect anyone to do in a hot path so I really think that's fine.

At the end of the day, these are convenience additions that also improve on discoverability - but at least now it's reusing the same global configuration of custom quantities instead of whatever the instance implementation decides to deliver. I don't think this is worth shoving into a separate nuget, since it adds very little bloat.

[lipchev]

I'm fine either way, but still can't see any good uses for having a convenience method for the UnitInfo<TUnit> - if it were the UnitInfo<TQuantity, TUnit> I guess I could see it being used as an instance factory or something, but this just feel like another set of breaking changes to avoid in the future.

[claude]

Code Review

Overview

Reverts the IQuantity.UnitInfo and IQuantity<TUnitType>.UnitInfo default interface members from #1649, and exposes GetUnitInfo() as extension methods available on all TFMs (removing the #if !NET guard).

Design

The rationale is well explained: DIMs on a struct-based type add boxing cost for every call, and a custom IQuantity implementor overriding UnitInfo would silently diverge from what UnitConverter/UnitAbbreviationsCache/QuantityFormatter actually use internally. The extension-method form avoids both problems.

The overload resolution table in the PR description is accurate and helpful:

• Length q -> infers GetUnitInfo<Length, LengthUnit> -> returns UnitInfo<Length, LengthUnit> (richer)
• IQuantity q -> GetUnitInfo(IQuantity) -> returns UnitInfo (non-generic fallback)
• IQuantity<TUnit> q -> falls back to non-generic overload (loses typed return vs previous UnitInfo<TUnit>)

The loss of typed return for IQuantity<TUnit> callers is an acceptable trade-off given how rarely that specific constraint appears compared to concretely-typed receivers.

Breaking Changes

Removes IQuantity.UnitInfo and IQuantity<TUnitType>.UnitInfo DIMs. Anyone who added these properties to a custom IQuantity implementation will get an "interface member not found" error on upgrade if they only override the removed DIM. Low risk since the DIMs were just introduced in #1649.

Tests

Renaming UnitInfo_* tests to GetUnitInfo_* is clean. The new test for GetUnitInfo<TQuantity, TUnit> returning the fully-typed UnitInfo<Length, LengthUnit> is a good regression guard for the overload resolution.

Summary

Clean revert + improvement. No concerns.

[angularsen]

I changed it to return UnitInfo<TQuantity, TUnit> instead of UnitInfo<TUnit>.