Arithmetic expressions #1083
Arithmetic expressions #1083
Conversation
same precedence group. In this case the operators are ordered by associativity.
|
|
||
| Binary `+` performs string concatenation. | ||
|
|
||
| ## Extensibility |
There was a problem hiding this comment.
I think these should be checked in as a Carbon source file, see https://discord.com/channels/655572317891461132/707150492370862090/943638327817547816
There was a problem hiding this comment.
I agree, but I also think this can be a follow-up.
proposals/p1083.md
Outdated
| division by even numbers. We could be more mathematically pure by refusing to | ||
| implement `<` and friends for `uN`, and similarly refusing to support `/`. | ||
| There is no single canonical total order for that ring, and because | ||
| multiplication by even numbers loses information, only odd numbers have |
There was a problem hiding this comment.
Not blocking: "multiplication by even numbers loses information" doesn't help me much, because I don't find it any more self-evident than "only odd numbers have multiplicative inverses". Others may have different experiences, though.
There was a problem hiding this comment.
Added "by discarding the high-order bit" to try to make it clearer why it's losing information in a way that hopefully resonates with a programmer-centric view of integers modulo 2N. I mean, I'm not sure how much I should be getting into the details here rather than just pointing to Wikipedia; maybe removing some of this text and just saying division isn't well-defined is a better plan?
There was a problem hiding this comment.
Added "by discarding the high-order bit" to try to make it clearer why it's losing information in a way that hopefully resonates with a programmer-centric view of integers modulo 2N.
I'm afraid that still doesn't help me much, because my naive intuition is that modular multiplication discards the high-order bits on overflow, regardless of whether the operands were even. I can sort of see what you're getting at, in that you can think of multiplication by an even number as multiplication by an odd number followed by a left-shift, but only after thinking for a bit (and being primed by the research that led me to suggest the Wikipedia link).
From this point of view, I think what's counterintuitive is that multiplication by an odd number doesn't lose information.
I mean, I'm not sure how much I should be getting into the details here rather than just pointing to Wikipedia; maybe removing some of this text and just saying division isn't well-defined is a better plan?
Yeah, I think all we really need to say here is that division isn't well-defined (I'm not sure we even need to single out even numbers), and give a citation for people who find that surprising. That's complicated by the fact that the citation talks about multiplicative inverses rather than division per se, so I think it's worth keeping enough text to connect the dots from "multiplicative inverse" to "division", but I think we can safely drop the "loses information" part.
There was a problem hiding this comment.
Removed mention of even numbers here because it distracts from the point.
There was a problem hiding this comment.
Largely based on the amazing reviews by everyone else -- thansk for that!
I've not heard or seen any concerns with this direction, including from the leads, so approving.
Some wording clarifications below, but none change the meaning of the proposal, so feel free to submit whenever -- I'm happy with followups as needed here.
|
|
||
| Binary `+` performs string concatenation. | ||
|
|
||
| ## Extensibility |
There was a problem hiding this comment.
I agree, but I also think this can be a follow-up.
proposals/p1083.md
Outdated
| program behavior correct. | ||
| - Division by zero is still not handled. | ||
|
|
||
| ### Guarantee that all overflow errors are trapped |
There was a problem hiding this comment.
This summary doesn't for me directly reflect the first paragraph...
I think the term "trapped" here isn't a good term, both due to imprecision and unwelcoming/hostile associations. Is there a more precise, and mechanical term or phrase we could use without referring to a particular hardware construct that is named this way? Maybe "are diagnosed or produce mathematically correct results", is that too wordy? Wolud "are diagnosed" be a reasonable way to describe the various ways that program execution doesn't proceed and some dynamic error state is produced?
There was a problem hiding this comment.
Switched to "Guarantee that the program never proceeds with an incorrect value after overflow", which is a bit verbose but I think is more accurate.
proposals/p1083.md
Outdated
| Floating-point types use IEEE 754 semantics, with round-to-nearest rounding | ||
| mode, no signaling NaNs, and no floating-point exceptions. | ||
|
|
||
| The `+` operator is also supported on strings, and performs concatenation. |
There was a problem hiding this comment.
Just for the record, I hope we can remove this in the future. I really dislike this form of concatenation. But a) I don't think its worth changes here, and b) we don't really have a robust string manipulation APi yet so there isn't really an alternative. It seems very reasonable to leave this in until we've made it convenient to avoid. =]
Anyways, nothing to do here in the proposal. =]
There was a problem hiding this comment.
I had intended to remove this based on earlier push-back -- this rule is gone from the design update but I forgot to remove it here. Updated proposal to say it takes no stance on this question; #457 covers this.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
github-actions
bot
added
proposal accepted
Add support for arithmetic operators: - Unary `+`. - Binary `+`, `-`, `*`, `/`, `%`. Specify their behavior for integer and floating-point types. Signed integer overflow is a programming error, handled in various ways. Unsigned integer overflow is specified as wrapping around, intended for hashing / crypto / PRNG use cases. Co-authored-by: jonmeow <46229924+jonmeow@users.noreply.github.com> Co-authored-by: Chandler Carruth <chandlerc@gmail.com> Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Add support for arithmetic operators:
+.+,-,*,/,%.Specify their behavior for integer and floating-point types. Signed integer overflow is a programming error, handled in various ways. Unsigned integer overflow is specified as wrapping around, intended for hashing / crypto / PRNG use cases.