-
Notifications
You must be signed in to change notification settings - Fork 94
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: compound assignment operations on quantities now behave the same…
… as on the underying representation types Resolves #137
- Loading branch information
Showing
3 changed files
with
50 additions
and
23 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7445585
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is allowing truncation with
+=
and-=
consistent with where we don't allow it?It's OK to reject those for consistency.
The problem before was that truncation happened in the caller,
which gave a different result than the operation on the representation types.
Assuming common types,
a @ b
should either work and have the same numerical value asa.numerical_value @ b.numerical_value
,or it shouldn't work.
7445585
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, you are probably right. I changed all of the rules for compound assignment operators to prevent narrowing.