# FlexUnits.jl 0.3.0, Support for Unitful-like inference

**URL:** <https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903>\
**Category:** Package Announcements\
**Created:** [January 6, 2026, 2:00am UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903 "2026-01-06T02:00:04Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [January 15, 2026, 4:34pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/21 "2026-01-15T16:34:37Z")

</div>

After attempting compatiblity with DifferentialEquations.jl and achieving some successful results, I think it’s best if I follow Unitful’s convention to subtype Quantity to Number and add a new FlexQuantitiy type that can contain other types.

---

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [January 15, 2026, 4:38pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/22 "2026-01-15T16:38:04Z")

</div>

After digging into some of the existing problems with unit packages and linear algebra, I figured out some interesting solutions which are planned for the next major release. I’ll be testing against some examples with DifferentialEquations.jl (I’m already successful with mixed units and the Tsit5() solver) and hopefully with better LinearAlgebra support, I’ll be able to support more solvers.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 15, 2026, 5:51pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/23 "2026-01-15T17:51:32Z")

</div>

> [@oschulz](#):
>
> It’s up to the package maintainers, of course, but maybe they might be interested in buying into UnitsBase?

Just quickly dropping by to say that yes, as the maintainer of DynamicQuantities.jl, I’m happy to support this too, via making DQ.Quantity a subtype of some UnitsBase abstract type.

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [January 15, 2026, 8:31pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/24 "2026-01-15T20:31:35Z")

</div>

And abstact quantit supertype might be even better than a trait-based approach. We currently need to dispatch to `RealOrRealQuantity` quite often in several physics packages I’m involved in (lot’s of code that can take real numbers with and without units, be really shouldn’t be given complex numbers and so on). So having a kind of `AbstractQuantity` (enabling `RealOrRealAbstrastQuantity` and the like), supported by all unit packages, would be awesome.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 15, 2026, 10:05pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/25 "2026-01-15T22:05:42Z")

</div>

> [@oschulz](#):
>
> dispatch to `RealOrRealQuantity`

Oh I wish the default/the only quantity type just was `<: Real`… Would solve quite a few inconveniences.  
Don’t remember seeing strong arguments against, other than “unitful quantities have been `<: Number` for ages”.

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [January 18, 2026, 1:59pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/26 "2026-01-18T13:59:11Z")

</div>

> [@aplavin](#):
>
> Don’t remember seeing strong arguments against

E.g. Electrical Engineering commonly works with complex units, like complex impedance.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 18, 2026, 3:28pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/27 "2026-01-18T15:28:08Z")

</div>

@Eben60 sure, complex numbers with units are often useful – same as vectors with units, or quaternions with units, or a bunch of other objects.  
But how is that related to `Quantity <: Real` vs current `Quantity <: Number`? If anything, having `Quantity <: Real` would make it easier to support complex unitful numbers – it would just work automatically, with `Complex{Quantity}`.

---

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [January 19, 2026, 4:11pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/28 "2026-01-19T16:11:00Z")

</div>

> [@aplavin](#):
>
> Oh I wish the default/the only quantity type just was `<: Real`… Would solve quite a few inconveniences.  
> Don’t remember seeing strong arguments against, other than “unitful quantities have been `<: Number` for ages”.

I actually tried making Quantity something like `Quantity{<:Real, <:AbstractUnitLike} <: Real` but it was way more trouble than it was worth in my experience (tons of ambiguities, conflicts with dual numbers) so I dropped it. I generally find that this isn’t an issue because there’s two patterns I use to deal with this:

1. I can always make my code support “Number”, and when I do, I write it with the express intent to support quantities and complex numbers.
2. If there’s a third party function that takes “Real” arguments, I simply `ustrip` the inputs to SI, run it on raw Real numbers, and then add the expected output dimensions at the end (because the result will be in SI). Even when I supported `Real`, attempting to put units into these functions failed 90% of the time, so I had to use this pattern anyway.

In fact, my next major release is going to add objects that make Pattern 2 widely used for

- Linear algebra (because it’s significantly faster and more reliable)
- Automatic differentiation (because it’s necessary to make it work)
- Generic nonlinear functions (because it’s often necessary for black box models)

For most cases, Pattern 2 is the way. Is there any reason why this doesn’t work for you?

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 19, 2026, 4:32pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/29 "2026-01-19T16:32:41Z")

</div>

> [@Deduction42](#):
>
> I can always make my code support “Number”

“My code” is totally fine indeed: it can be made as generic as needed.

> [@Deduction42](#):
>
> If there’s a third party function that takes “Real” arguments, I simply `ustrip` the inputs to SI

That works, of course, but loses a huge part of Unitful appeal – “everything” just works with unitful values.  
There is _lots_ of Julia code in the wild that is restricted to `Real`. Two examples I remember out of my head, that would 100% make sense for Unitful:

- `Base.searchsorted(::AbstractRange{<:Real}, ::Real)` is faster than the generic AbstractArray fallback because it does division instead of binary search
- `StatsBase.weights` requires `AbstractVector{<:Real}`

---

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [January 19, 2026, 5:42pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/30 "2026-01-19T17:42:02Z")

</div>

> [@aplavin](#):
>
> That works, of course, but loses a huge part of Unitful appeal – “everything” just works with unitful values.

That statement right there runs counter to most of my experience, especially with mixed units which are a nightmare to deal with in Unitful. Moreover, mixed units are the only case I really care about because when units are all the same, the answer is obvious. This is why I wrote FlexUnits; to be able to support more of Julia with mixed-unit functionality. Because even with algorithms being compatible with `Number`, they fail more often than not. Real is even worse, because when people write code in Real, they seldomly think about units. To most Julia programmers, the line between pure black-box numeric code and code that supports units is drawn between Real and Number, or even between Number and Any.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 19, 2026, 6:33pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/31 "2026-01-19T18:33:02Z")

</div>

> [@Deduction42](#):
>
> That statement right there runs counter to most of my experience

Sometimes interesting how different can experiences be 🙂

> [@Deduction42](#):
>
> especially with mixed units which are a nightmare to deal with in Unitful

What exactly do you mean by “mixed units”? Unitful preserves units as-is – stuff like “erg/s” remains in these units as long as possible even though it mixes si/non-si; and even “cm^3/pc” remain, which isn’t just si + nonsi, but also the same dimension in both numerator and denominator.

> [@Deduction42](#):
>
> To most Julia programmers, the line between pure black-box numeric code and code that supports units is drawn between Real and Number, or even between Number and Any.

Citation needed 🙂 A lot of `Number` code just works with Unitful (that’s a major part of what makes Unitful a big success story of Julia).  
And there are quite a few functions/types in the wild that are restricted to `<: Real` and cannot take Quantities – but otherwise would just work, if not for this type constraint.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 19, 2026, 6:35pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/32 "2026-01-19T18:35:44Z")

</div>

> [@Deduction42](#):
>
> Because even with algorithms being compatible with `Number`, they fail more often than not.

I wonder if you have some examples of code that silently fails with Unitful – ie, without throwing an error?

---

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [January 19, 2026, 6:48pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/33 "2026-01-19T18:48:27Z")

</div>

> [@aplavin](#):
>
> Don’t remember seeing strong arguments against, other than “unitful quantities have been `<: Number` for ages”.

> [@aplavin](#):
>
> I wonder if you have some examples of code that silently fails with Unitful – ie, without throwing an error?

It isn’t about silently throwing errors, it’s about effort vs. reward. Basically, disambiguating “Number” and “Real” is much easier than disambiguating “Real” and all its subtypes, especially since there’s a lot of other important Real types that are not present in Base (like dual numbers). If I simply subtype “Number”, I only have to case out Complex; otherwise, I have to case out all the subtypes of Real and repeat a lot of code for all of these cases in additional extensions (especially with dual numbers) to get rid of ambiguities and excessive invalidations. It truly is a lot of work to do this, and considering that most code which restricts to “Real” isn’t written to support quantities with units anyway, most of the time you don’t get any benefit for this additional work and maintenance burden.

Even in my own code I tend to do follow this convention for Real; for example, in polynomial regression. I do find it comforting to be able to draw the line at Real when it comes to expectations toward supporting units.

If this is really important to you, maybe you should fork Unitful.jl and prove out that it can be done without arduous amounts of effort. I tried this and failed. Maybe you can succeed.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 19, 2026, 6:53pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/34 "2026-01-19T18:53:01Z")

</div>

> [@Deduction42](#):
>
> It isn’t about silently throwing errors

“Silently failing” and “throwing errors” are really the opposite ends of a behavior spectrum, not the same thing 🙂

> [@Deduction42](#):
>
> disambiguating “Number” and “Real” is much easier than disambiguating “Real” and all its subtypes

Thanks, that can be a totally reasonable argument for “why not make units \<: real”. Do you know why this disambiguation is easier for numbers vs reals? There are clearly more Number subtypes in the ecosystem than Real subtypes…

---

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [January 19, 2026, 6:58pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/35 "2026-01-19T18:58:48Z")

</div>

Not direct subtypes. There is only two direct subtypes of Number in Base, which are “Complex” and “Real”. Moreover, I don’t care about supporting “Number” subtypes outside of “Base”, and FlexUnits.jl won’t work with those unless someone builds an extension. There are a number of direct “Real” subtypes outside of Base that I care about, particularly “Dual”; this is particularly difficult to step around. This is precisely the reason I dropped Real support. If I simply make Quantity a Number, and disambiguate it from all Real numbers, then “Dual” numbers simply work with little to no effort. Note however, you can’t autodiff quantities, you can only autodiff THROUGH quantities by modifying the values. When trying to support Real, I still had to do this PLUS define all the disambiguating methods which are a LOT.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 19, 2026, 7:07pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/36 "2026-01-19T19:07:35Z")

</div>

I see, basically the reason you found it easier to disambiguate vs Number is just because there are fewer subtypes of Number that you care about – than similar subtypes of Real.  
Makes sense practically, of course!

---

<div class="post-metadata">

**Author:** ![RGonTheNoble](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rgonthenoble/32/209422_2.png) [@RGonTheNoble](https://discourse.julialang.org/u/RGonTheNoble)\
**Post date:** [January 20, 2026, 5:55pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/37 "2026-01-20T17:55:17Z")

</div>

The other thing to note is that if all quantities are generic, it’s actually pretty easy to wrap these methods as well. For example, in the current iteration of FlexUnits, this works:

```julia
Base.searchsorted(v::Quantity{<:AbstractVector{<:Real}}, x::Quantity{<:Real}) = searchsorted(ustrip(v), ustrip(unit(v), x))

julia> searchsorted((1:5)*u"m/s", 3*u"m/s")
3:3

```

Yes, this means I need to build functions to wrap all possible functions, but I’d have to do that anyway if I subtyped to Real to disambiguate. There’s no free lunch for me and it’s far easier for end users to patch individual functions in their code than it is to disambiguate someone else’s code.

To make things worse, in future versions, the first argument would need to be FlexQuant or QuantUnion because I ended up having to subtype Quantity to Number in order to make a lot of other things (like DifferentialEquations) work. This is why I wish the convention was not to subtype Quantity to anything at all or some way to split the supertyping so that

```julia
Quantity{<:Any} <: Any
Quantity{<:Number} <: Number
Quantity{<:AbstractArray{T}} <: AbstractArray{T}

```

but I don’t think splitting the supertyping like this would be easy to implement.

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [February 6, 2026, 8:36am UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/38 "2026-02-06T08:36:41Z")

</div>

I think this is actually part of a larger issue - traced numbers in Reactant, for example, are also subtypes of `Number`, so it’s hard for user code to say “I need something kind of like a Real here” without taking on a heavy and very specialized dependency. We have a similar problem in Static, where the static integer is a `Number` not a `Real`. And probably in other places too.

I think we can make a super-lightweight package for “unusual numbers” (and subtypes for the quantity, traced and static case) to solve this in a generic and user/dependency-friendly fashion. I’ll try to put together a quick prototype with proof of concept PRs on Unitful, FlexUnits and DynamicQuantities, Reactant and maybe Static as well, then we could iterate on naming, structure, etc.

---

<div class="post-metadata">

**Author:** ![Ickaser](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ickaser/32/28852_2.png) [@Ickaser](https://discourse.julialang.org/u/Ickaser)\
**Post date:** [February 11, 2026, 6:36pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/39 "2026-02-11T18:36:29Z")

</div>

> [@Deduction42](#):
>
> I think if you guys adopt UnitsBase for Unitful and DynamicQuantities, it will generate enough buy-in.

As a sometime contributor to Unitful, I’d love to see this go forward–would be happy to at least help review a PR, maybe could contribute one if it’s not too complicated.

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [February 12, 2026, 8:50pm UTC](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/40 "2026-02-12T20:50:09Z")

</div>

> [@oschulz](#):
>
> I think we can make a super-lightweight package for “unusual numbers” (and subtypes for the quantity, traced and static case) to solve this in a generic and user/dependency-friendly fashion.

Ok, here is my attempt, it’s called [NestedNumbers.jl](https://github.com/JuliaMath/NestedNumbers.jl) (working title, not registered yet), please see (and feel most welcome to take part in) the [NestedNumbers design discussion](https://github.com/JuliaMath/NestedNumbers.jl/issues/1). Any and everything, including the package name, is up for change.

[Previous page](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903.md?page=1)

[Next page](https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903.md?page=3)