And, or, not #680

zygoloid · 2021-07-27T01:08:40Z

Logical AND, OR, and NOT are important building blocks for working with Boolean values. This proposal introduces the and, or, and not operators to support these operations.

chandlerc

Really nice... My only comments are trying to make the alternatives section a little less ambiguous/unclear for readers.

proposals/p0680.md

jonmeow

FWIW I'm still mixed on and/or/not. On the one hand, I feel like there are lots of languages that use && and ||, and I feel like Python is kind of on its own here -- I worry that this will make Carbon feel more niche, and that this is a design decision being made due to a single (if major) bug in Chrome, which could possibly be addressed by restricting how bitwise operations work instead (and bitwise operations are rarer, my sense is probably by an order of magnitude). On the other hand, I do sympathize with readability, and maybe Python is enough precedent to make this stand.

jonmeow · 2021-07-27T15:38:24Z

proposals/p0680.md

+var x = cond1 == not cond2;
+```
+
+is invalid and requires parentheses, and


I'm confused why the above example on line 197 is ambiguous in a way that would lead to it being invalid, can you clarify this? I would've thought there's no operand other than not touching cond2 that could lead to an alternative interpretation for which precedence would be needed to resolve...

not is lower precedence than ==, so we can't have a not expression as a subexpression of an == expression following the precedence proposal. We could choose to have different rules on the left and right side of ==, so not a == b would mean not (a == b) but b == not a would mean b == (not a), but I think overall that would be too confusing, and it creates problems with things like a == not b == c, which would parse as a == (not (b == c)) using the normal operator precedence parser approach.

I guess I still don't understand why this fails but not cond1 == cond2 should work (I would have thought that would be the ambiguous case indicative of an error).

Do what you like with this commentary, I don't think this is specific to the keyword spelling. At this point I'm not really asking for changes/replies, just observing that I don't really understand the intended behavior.

FWIW, I think this is something that will become even less ambiguous with grammar and the design document so not worried about getting it perfect in the proposal.

proposals/p0680.md

jonmeow · 2021-07-27T19:03:36Z

I think I should note, using &&/||/! seems crucial to address directly. This had me looking more closely at the rationale, where I think it talks about the advantages of and, but I feel the disadvantages are overlooked.

jonmeow

(apparently, pending comments don't always attach to comments)

proposals/p0680.md

zygoloid

See also #682, which gives an example of what this proposal would look like if applied to the Carbon project's C++ code.

proposals/p0680.md

zygoloid · 2021-07-27T22:55:05Z

proposals/p0680.md

+var x = cond1 == not cond2;
+```
+
+is invalid and requires parentheses, and


not is lower precedence than ==, so we can't have a not expression as a subexpression of an == expression following the precedence proposal. We could choose to have different rules on the left and right side of ==, so not a == b would mean not (a == b) but b == not a would mean b == (not a), but I think overall that would be too confusing, and it creates problems with things like a == not b == c, which would parse as a == (not (b == c)) using the normal operator precedence parser approach.

proposals/p0680.md

chandlerc

Thanks, I think the text here is converging nicely. Some adjustments based on feedback on this thread (thanks!) and I'm going to create a blocking issue for deciding specifically on the strategy here.

chandlerc · 2021-07-28T00:54:52Z

proposals/p0680.md

+### Use punctuation spelling for all three operators
+
+We could follow the convention established by C and spell these operators as
+`&&`, `||`, and `!`. This would improve familiarity for people comfortable with
+this operator set.


I think this at least should be a blocking issue for the leads. I'll turn this comment into that issue.

I'd also suggest structuring this as advantages / disadvantages? Mostly I think that'll help extract some of the advantages of using && and similar spellings from the prose to make it clear that they do exist and are being considered.

proposals/p0680.md

chandlerc · 2021-07-28T02:14:19Z

Depends on #684

Co-authored-by: Chandler Carruth <[email protected]>

jonmeow · 2021-07-29T15:44:38Z

Apologies, I'm realizing this proposal is still in Draft according to the project. Did you mean to move it to the RFC column?

josh11b · 2021-07-29T15:58:19Z

Apologies, I'm realizing this proposal is still in Draft according to the project. Did you mean to move it to the RFC column?

Perhaps the automation should do that automatically once the PR itself is marked as ready for review?

jonmeow · 2021-07-29T17:03:17Z

It does if you switch project columns. It cannot change project columns on its own.

chandlerc

Blocking decision is resolved, LGTM.

I've left one minor suggested addition below and responded to the only unresolved comment thread I saw. If we need specific clarification, we'll have a place in a follow-up I think.

proposals/p0680.md

chandlerc · 2021-07-31T00:13:10Z

proposals/p0680.md

+var x = cond1 == not cond2;
+```
+
+is invalid and requires parentheses, and


FWIW, I think this is something that will become even less ambiguous with grammar and the design document so not worried about getting it perfect in the proposal.

Co-authored-by: Chandler Carruth <[email protected]>

Co-authored-by: Chandler Carruth <[email protected]> Co-authored-by: Richard Smith <[email protected]>

Proposal: use `and`, `or`, and `not` keywords in place of `&&`, `||`, `!`. Co-authored-by: Chandler Carruth <[email protected]>

Co-authored-by: Chandler Carruth <[email protected]> Co-authored-by: Richard Smith <[email protected]>

zygoloid added the proposal A proposal label Jul 27, 2021

zygoloid requested a review from a team July 27, 2021 01:08

google-cla bot added the cla: yes PR meets CLA requirements according to bot. label Jul 27, 2021

zygoloid marked this pull request as ready for review July 27, 2021 02:20

Initial draft of proposal #680: and, or, and not.

6cbe597

chandlerc requested changes Jul 27, 2021

View reviewed changes

proposals/p0680.md Outdated Show resolved Hide resolved

proposals/p0680.md Outdated Show resolved Hide resolved

fowles reviewed Jul 27, 2021

View reviewed changes

proposals/p0680.md Outdated Show resolved Hide resolved

proposals/p0680.md Outdated Show resolved Hide resolved

jonmeow reviewed Jul 27, 2021

View reviewed changes

proposals/p0680.md Outdated Show resolved Hide resolved

zygoloid mentioned this pull request Jul 27, 2021

Use and, or, not in C++ #682

Closed

Responses to review comments.

10b651b

zygoloid commented Jul 27, 2021

View reviewed changes

chandlerc requested changes Jul 28, 2021

View reviewed changes

chandlerc mentioned this pull request Jul 28, 2021

Should Carbon use and, or, and not; or &&, ||, and !? #684

Closed

zygoloid and others added 3 commits July 28, 2021 15:27

Update proposals/p0680.md

f880fa5

Co-authored-by: Chandler Carruth <[email protected]>

Respond to review comments.

502c621

Expand background and alternatives with some more observations.

963a3c2

github-actions bot added the proposal rfc Proposal with request-for-comment sent out label Jul 31, 2021

chandlerc approved these changes Jul 31, 2021

View reviewed changes

zygoloid and others added 3 commits August 3, 2021 15:32

Update proposals/p0680.md

aa33c85

Co-authored-by: Chandler Carruth <[email protected]>

prettier cleanup.

39ada99

Merge branch 'trunk' into proposal-and-or-not

86fca6e

zygoloid merged commit fac4343 into carbon-language:trunk Aug 3, 2021

github-actions bot added proposal accepted Decision made, proposal accepted and removed proposal rfc Proposal with request-for-comment sent out labels Aug 3, 2021

zygoloid mentioned this pull request Jan 19, 2022

Document and, or, and not from #680 #1032

Merged

jonmeow added a commit that referenced this pull request Jan 27, 2022

Document and, or, and not from #680 (#1032)

2fc4d10

Co-authored-by: Chandler Carruth <[email protected]> Co-authored-by: Richard Smith <[email protected]>

zygoloid deleted the proposal-and-or-not branch March 11, 2022 01:02

chandlerc added a commit that referenced this pull request Jun 28, 2022

And, or, not (#680)

86ae4c6

Proposal: use `and`, `or`, and `not` keywords in place of `&&`, `||`, `!`. Co-authored-by: Chandler Carruth <[email protected]>

chandlerc pushed a commit that referenced this pull request Jun 28, 2022

Document and, or, and not from #680 (#1032)

6218aff

Co-authored-by: Chandler Carruth <[email protected]> Co-authored-by: Richard Smith <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

And, or, not #680

And, or, not #680

zygoloid commented Jul 27, 2021 •

edited

Loading

chandlerc left a comment

jonmeow left a comment

jonmeow Jul 27, 2021

zygoloid Jul 27, 2021

jonmeow Jul 27, 2021

chandlerc Jul 31, 2021

jonmeow commented Jul 27, 2021

jonmeow left a comment

zygoloid left a comment

zygoloid Jul 27, 2021

chandlerc left a comment

chandlerc Jul 28, 2021

chandlerc commented Jul 28, 2021

jonmeow commented Jul 29, 2021

josh11b commented Jul 29, 2021

jonmeow commented Jul 29, 2021

chandlerc left a comment

chandlerc Jul 31, 2021

And, or, not #680

And, or, not #680

Conversation

zygoloid commented Jul 27, 2021 • edited Loading

chandlerc left a comment

Choose a reason for hiding this comment

jonmeow left a comment

Choose a reason for hiding this comment

jonmeow Jul 27, 2021

Choose a reason for hiding this comment

zygoloid Jul 27, 2021

Choose a reason for hiding this comment

jonmeow Jul 27, 2021

Choose a reason for hiding this comment

chandlerc Jul 31, 2021

Choose a reason for hiding this comment

jonmeow commented Jul 27, 2021

jonmeow left a comment

Choose a reason for hiding this comment

zygoloid left a comment

Choose a reason for hiding this comment

zygoloid Jul 27, 2021

Choose a reason for hiding this comment

chandlerc left a comment

Choose a reason for hiding this comment

chandlerc Jul 28, 2021

Choose a reason for hiding this comment

chandlerc commented Jul 28, 2021

jonmeow commented Jul 29, 2021

josh11b commented Jul 29, 2021

jonmeow commented Jul 29, 2021

chandlerc left a comment

Choose a reason for hiding this comment

chandlerc Jul 31, 2021

Choose a reason for hiding this comment

zygoloid commented Jul 27, 2021 •

edited

Loading