5

In current C++ when body of if statements contain only one command then:

Parenthesis around if condition are mandatory but block are optional. So, both examples are OK:

if ( condition ) { return 0; }
if ( condition ) return 0;

But is it theoretically possible to do it also oppositely?:

Blocks mandatory and parenthesis around if condition optional:

if ( condition ) { return 0; }
if condition { return 0; }

Is it teoretically possible to extend C++ syntax this way? (for example as extension in some C++ compiler or theoretically in some future C++ standard). Or collides this hypothetical extension with some other C++ syntactic rule?

Note: Personal opinions if this extension should be made or not are irelevant - that's not the question.

EDIT:

Strict interpretation of question has ben answered by Jules.

But if "optional parenthesis" will not mean "optional in every case" but instead "optional in most of cases", then proposed change in C++ still can be made. In rare corner cases like that in Jules answer, compiler can detect ambiquity, and output error:

"Ambiguous if condition. You must explicitly use parenthesis to resolve it"
  • 1
    As long as the block is mandatory and no opening brace can appear within the condition, you could easily change the language definition so the parentheses are optional. But C++ syntax is pretty hairy, and I'm not certain that a complex condition might not legitimately contain a {. – Kilian Foth Jan 7 '15 at 7:47
  • 1
    A condition certainly can contain an open brace (e.g. in a lambda expression). – Jules Jan 7 '15 at 8:29
  • Why on earth do you want to make more things optional? I'd rather have C++ make parenthesis: mandatory in all cases. – Pieter B Jan 7 '15 at 9:36
  • 1
    @Pieter B: Then sorry for confusion. I written "proposed change" after and in same sense as it was used by Jules in "...your proposed changed:". Id does not mean i am proposing it effectively. My interest is theoretical. Dont fear i will change Your loved C++ :-) – user3123061 Jan 7 '15 at 9:55
  • 1
    Note that ambiguity is more of a problem than you appear to think it is. Writing a compiler that will detect ambiguous usages and produce an error is very difficult. I believe it would preclude using an LALR parser, for instance, so you would be unable to write a useful C++ parser using most parser generators. (Currently, my understanding is that an LALR parser can parser C++ if the lexical analyzer is aware of the names of defined types, which is a bit of a hack, but does work). – Jules Jan 7 '15 at 19:41
13

I don't believe any such extension could be made. The problem is that there doesn't seem to be any way to tell if a brace is the start of an initializer or not. For example, the following code would appear to be ambiguous under your proposed change:

if new T{} { hello(); }

The two interpretations are:

  1. Create a new T with an empty initializer list, and if the result is not null call "hello".

  2. Create a new T with the default constructor, and if the result is not null, do nothing. Then call "hello" in either case.

  • Well, that can be solved easily: Just declare how the tie is broken. I think the only sane choice is: Presume initializer. – Deduplicator Feb 21 '16 at 22:33
  • 1
    That would be a bad idea, I think, because that potentially violates the principle of least surprise, having an actual code block being subsumed into an initializer because it simply looks like it could be one. – Jules Feb 22 '16 at 17:35
  • There are lots of places things would be ambiguous without extra-rules, just look at templates, or multi-character tokens. – Deduplicator Feb 22 '16 at 20:35
0

No. The C and C++ standards explicitly specify that the if keyword must be followed by a parenthesized expression. The compiler is required to reject any program where that's not the case.

The relevant section in the C++ standard is §6.4 Selection statements:

Selection statements choose one of several flows of control.

selection-statement:

if ( condition ) statement
if ( condition ) statement else statement

This is the BNR grammar for the if statement, and the ( and ) are specified and therefore required for the statement to match as valid.

To make your suggested syntax valid will require a revision to the standard, which you are free to propose to the ISO Working Group 21, but you will be expected to defend the proposal.

  • 8
    I think the OP knows that it's illegal and the standard assures that it's illegal. But could the grammar be changed to omit the (), or would that introduce new syntactic ambiguity? – Kilian Foth Jan 7 '15 at 7:49
  • 1
    The standard could be changed, yes, but he'll have to take that up with the committee. I don't see any reason they'd accept it, though. – greyfade Jan 7 '15 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.