Consider separating "forcing" from explicit-Rep #122
Labels
⬇️ affects: code (interfaces)
Affects the way end users will interact with the library
📁 kind: enhancement
New feature or request
💪 effort: large
Milestone
Comments
chiphogg
added
📁 kind: enhancement
chiphogg
added
💪 effort: large
⬇️ affects: code (interfaces)
|
On further reflection and discussion, I'm leaning towards |
chiphogg
added a commit
that referenced
this issue
Aug 29, 2023
These are variants of `.as` and `.in` for both `Quantity` and `QuantityPoint`. When we precede these with the "coerce" vocabulary word, they become forcing, ignoring the safety checks for truncation and overflow. This new syntax has two major advantages over the explicit-Rep version. First, it makes the intent clearer. Second, it stops forcing users to repeat the rep when they want the same rep they started with, which I think is the usual case. (Thus, without these APIs, explicit-rep obscures intent: one never knows whether the author wanted a cast, or wanted to bypass the safety checks.) It also unlocks another, later improvement: we will be able to extend the safety checks to the explicit-rep versions! But we won't attempt that for a while because that's a breaking change. There may be other APIs that would benefit from using the "coerce" vocabulary word instead of explicit-rep. However, we'll start with just these, both because they're the overwhelmingly most common use case, and because it gives us a chance to try out these ideas in practice for a while. Helps #122. We'll start with just these functions because they're by far the most prevalent. Later on, we can
chiphogg
added a commit
that referenced
this issue
Sep 1, 2023
These are variants of `.as` and `.in` for both `Quantity` and `QuantityPoint`. When we precede these with the "coerce" vocabulary word, they become forcing, ignoring the safety checks for truncation and overflow. This new syntax has two major advantages over the explicit-Rep version. First, it makes the intent clearer. Second, it stops forcing users to repeat the rep when they want the same rep they started with, which I think is the usual case. (Thus, without these APIs, explicit-rep obscures intent: one never knows whether the author wanted a cast, or wanted to bypass the safety checks.) It also unlocks another, later improvement: we will be able to extend the safety checks to the explicit-rep versions! But we won't attempt that for a while because that's a breaking change. There may be other APIs that would benefit from using the "coerce" vocabulary word instead of explicit-rep. However, we'll start with just these, both because they're the overwhelmingly most common use case, and because it gives us a chance to try out these ideas in practice for a while. To test this PR, I added new unit tests to cover all of the use cases. I also rendered the docs locally and checked that the links worked as intended. Helps #122.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have always conflated these ideas, probably because
static_castdoes both. But it could be nice to be able to write, say,inches(50).force_as(feet): we wouldn't need to repeat theRep, and the "force" makes the potential lossiness more obvious. This would free upq.as<T>(unit)to respect the safety checks.The text was updated successfully, but these errors were encountered: