Always return Quantity, not raw numbers (breaking change) #185
Labels
⬇️ affects: code (interfaces)
Affects the way end users will interact with the library
📁 kind: enhancement
New feature or request
💪 effort: medium
Milestone
Comments
chiphogg
added
📁 kind: enhancement
|
+1 for this change... There are certainly tradeoffs, but I'll also add that this could unlock the ability to create more dimensionless units - for example, |
|
One slight complication to consider is that some users might have functions that are generic not just across different This means that
|
chiphogg
added
💪 effort: small
💪 effort: medium
and removed
💪 effort: large
💪 effort: small
labels
chiphogg
added a commit
that referenced
this issue
Nov 29, 2024
This means that `Quantity` arithmetic now always and consistently returns `Quantity`, even when all units exactly cancel out. Formerly, we returned a raw number in that latter case. We thought this would make the library easier to use, but it actually just made it harder to reason about. The new policy should be simpler generally. What's more, `as_raw_number` is a nice, explicit, callsite-readable way to "exit" the library _exactly when_ such exiting is safe and well formed. It gives us _more_ than we had before, because now we can handle _non-unitless_ dimensionless results --- exactly when they are safe to convert. We also remove `stdx::identity`, because without this feature, we have no further need of it. Docs are updated. I tested the results using `au-docs-serve`, including the new internal links to the new section. Fixes #185.
chiphogg
added a commit
that referenced
this issue
Nov 29, 2024
This lets us pave the way to change the behavior of quantity arithmetic when all units cancel out (#185). If we make this change all at once, it'll generally be too big and hard to handle. But if we provide this utility now, then people can migrate individual callsites gradually over time. Then, at the end (probably 0.5.0?), making the switch to the new behavior won't be such a big change. Helps #185.
chiphogg
added a commit
that referenced
this issue
Nov 29, 2024
This lets us pave the way to change the behavior of quantity arithmetic when all units cancel out (#185). If we make this change all at once, it'll generally be too big and hard to handle. But if we provide this utility now, then people can migrate individual callsites gradually over time. Then, at the end (probably 0.5.0?), making the switch to the new behavior won't be such a big change. Helps #185.
chiphogg
added a commit
that referenced
this issue
Nov 29, 2024
This lets us pave the way to change the behavior of quantity arithmetic when all units cancel out (#185). If we make this change all at once, it'll generally be too big and hard to handle. But if we provide this utility now, then people can migrate individual callsites gradually over time. Then, at the end (probably 0.5.0?), making the switch to the new behavior won't be such a big change. Helps #185.
chiphogg
added a commit
that referenced
this issue
Dec 2, 2024
This lets us pave the way to change the behavior of quantity arithmetic when all units cancel out (#185). If we make this change all at once, it'll generally be too big and hard to handle. But if we provide this utility now, then people can migrate individual callsites gradually over time. Then, at the end (probably 0.5.0?), making the switch to the new behavior won't be such a big change. Helps #185.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, the result of a Quantity computation whose unit is equivalent to 1 is a raw number, rather than a Quantity equivalent to
unos. I made this decision because people generally expect this kind of computation to produce a raw number. We do provide implicit convertibility to the raw number type, but this can sometimes fail to trigger. Experience shows that the only thing that always acts like a raw numeric type is that type itself.I believe that further experience has shown this to be a mistake. It makes generic programming too hard. I used to think this was fine, because generic programming is mainly the domain of more experienced users, who will know how to handle this. I was wrong: the reason it's still a problem is that users can't be confident whether they'll get a Quantity or raw number just from inspecting a computation. If we refactor and change the unit of one of the participating quantities, it can even switch from one to the other!
The way to solve this is to provide some idiomatic function --- say,
as_raw_number(...)--- which "unpacks" a dimensionless quantity. This helps other (non-unity) dimensionless use cases, too. Alternatively, we could just tell everyone to write.in(unos).This is a breaking change. The best time to do this would be when we're nearly ready to release 0.4.0. We will also need to use Aurora's AV repo to see how "bad" this change would be in terms of what it does to the code.
The text was updated successfully, but these errors were encountered: