-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
And, or, not #680
And, or, not #680
Conversation
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.
Really nice... My only comments are trying to make the alternatives section a little less ambiguous/unclear for readers.
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.
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.
proposals/p0680.md
Outdated
var x = cond1 == not cond2; | ||
``` | ||
|
||
is invalid and requires parentheses, and |
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.
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...
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.
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.
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.
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.
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.
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.
I think I should note, using |
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.
(apparently, pending comments don't always attach to comments)
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.
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
Outdated
var x = cond1 == not cond2; | ||
``` | ||
|
||
is invalid and requires parentheses, and |
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.
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.
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.
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.
proposals/p0680.md
Outdated
### 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. |
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.
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.
Depends on #684 |
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
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? |
It does if you switch project columns. It cannot change project columns on its own. |
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.
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
Outdated
var x = cond1 == not cond2; | ||
``` | ||
|
||
is invalid and requires parentheses, and |
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.
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 <chandlerc@gmail.com>
Proposal: use `and`, `or`, and `not` keywords in place of `&&`, `||`, `!`. Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Logical AND, OR, and NOT are important building blocks for working with Boolean values. This proposal introduces the
and
,or
, andnot
operators to support these operations.