Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we allow qp.quantity_from(QuantityPoint )? #507

Open
mpusz opened this issue Oct 19, 2023 · 0 comments
Open

Should we allow qp.quantity_from(QuantityPoint )? #507

mpusz opened this issue Oct 19, 2023 · 0 comments
Labels
design Design-related discussion question Further information is requested

Comments

@mpusz
Copy link
Owner

mpusz commented Oct 19, 2023

quantity_point::quantity_from(PointOrigin) was added as a type safety interface over the previous getter quantity_point::quantity_from_origin() which was deemed unsafe.

Also, we now have quantity_point::quantity_ref_from(PointOrigin) that returns the reference to the underlying storage if the provided origin is the same as the one used in the quantity_point.

The question is, should we add an overload quantity_point::quantity_from(QuantityPoint) that takes QuantityPoint as an argument? I can see some benefits from doing so. On the other hand, quantity_point::quantity_ref_from(QuantityPoint) has no sense and should not be exposed.

quantity_from just subtracts the argument from *this, so it is not something that is complicated, and the user could not easily do it just with a subtraction. It was added mostly to extend quantity_point::quantity_ref_from(QuantityPoint), which had to be there. Also, I noticed that it helps do subtraction in the correct order. I already made the mistake of accidentally exchanging the argument, and I got a negative quantity as a result when a positive one was expected.

@mpusz mpusz added question Further information is requested design Design-related discussion labels Oct 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design-related discussion question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant