if/else

[jonmeow]

No description provided.

[jonmeow]

Proposal links (add links as proposal evolves):

• Evolution links:
  • Proposal PR
  • RFC topic
  • Decision topic
  • Decision PR
  • Announcement
• Related links (optional):
  • Draft (Google doc)
  • Simplified proposals for echoing C++ syntax (topic)

[fowles]

I find "basically" to confuse this point. What is if anything is different from C++?

[jonmeow]

Removing "basically", it's not a great word to add anyways.

[zygoloid]

I have no concerns. LGTM!

[josh11b]

Should this also change the "provisional" text in the language overview?

[jonmeow]

Should this also change the "provisional" text in the language overview?

This is just a proposal doc, and doesn't include design changes. Those would be handled separately, through code review.

[jsiek]

This looks good.

Small request: could you add a few complete test programs and expected results (for addition to the testdata/ directory of the executable semantics).

[jonmeow]

Sorry, but I'd really rather not block this on changes to executable semantics. That is not a requirement, and honestly I'd rather just move forward (with the proposal).

[jsiek]

Hi Jon, My comment wasn't intended to block this... just meant as encouragement to collaborate with me on the executable semantics in parallel. I've added three test cases this afternoon... you might take a look to see if you think I've got the corner cases covered.

[chandlerc]

LGTM for what it's worth.

I'd personally probably go one step further and require {}s and support basically:

if (<expression>) { ... } [ else if (<expression>) { ... } ][ else { ... } ]

And none of the braces are optional.

This is a strict subset of C++, with no further features. But it has no ambiguous else or goto-fail concerns or optional braces.

That said, I am 100% fine with this proposal going in, and suggesting the above as a follow-up to restrict things unless Jon and others specifically want to narrow to this subset in this early proposal.

[dabrahams]

Not a comment on the proposal, which is fine. Just to note in response to @chandlerc, if the braces are required, there's no need to require the parens. One nice effect that has is that C++ programmers' old instincts to put the parens in still creates legal code.

[chandlerc]

Not a comment on the proposal, which is fine. Just to note in response to @chandlerc, if the braces are required, there's no need to require the parens.

Definitely an option, but not one I'd even want to consider here as that goes beyond simple sunsetting of C++. I'd suggest that and other extension like expression usage be later proposals.

[jonmeow]

@dabrahams Regarding parentheses, please note the third bullet in the alternative:

• Parentheses allow introducing syntactic variants in the future without
  ambiguity.
  • For example, C++'s if constexpr (...) wouldn't have been possible if
    the parentheses were optional.

(even if braces are required, this issue still applies, and thus parens should not be assumed to not be required)

Also, please be careful not to @ people who are not part of Carbon (@code).

[dabrahams]

@jonmeow could you explain where the constexpr ambiguity would come from when braces are required? That doesn't seem obvious to me.

Naturally @​code was a typo. I will endeavor in future only to type the things I mean to type.

[jonmeow]

Consider the parentheses-less code if constexpr int i = id(101) { } (borrowing the example from https://github.com/llvm/llvm-project/blob/main/clang/test/CXX/drs/dr9xx.cpp#L64).

That can be interpreted as either if (constexpr int i = id(101)) { } or if constexpr (int i = id(101)) { }. Note the resulting placement of parentheses differs.

An interesting, possibly more complex case of this is:

if (constexpr absl::string_view kFoo = "foo"; absl::StartsWith(arg, kFoo)) {

In either case, it's actually the difference between whether constexpr binds with what's on the left or the right. The braces requirement does not affect the ability to make a choice, only the parentheses.

[mmdriley]

Comment deadline set for March 9 -- ref https://forums.carbon-lang.dev/t/rfc-if-else-285/215/2

[mmdriley]

@jonmeow you're good to resolve and merge here

[jonmeow]

@mmdriley Can you approve for commit? (proposals need a review manager's approval)

[mmdriley]

Ack! Sorry I was blocking this.