And, or, not

[zygoloid]

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.

[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]

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...

[zygoloid]

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.

[jonmeow]

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.

[chandlerc]

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.

[jonmeow]

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)

[zygoloid]

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

[zygoloid]

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.

[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]

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.

[chandlerc]

Depends on #684

[jonmeow]

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]

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]

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.

[chandlerc]

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.