[Bug c++/41786] misparsing an object declaration - parameter may not have variably modified type

[jarausch at igpm dot rwth-aachen dot de]

------- Comment #2 from jarausch at igpm dot rwth-aachen dot de  2009-10-22 10:35 -------
(In reply to comment #1)
> I don't think this is misparsing this at all.  This is one place in the C++
> standard that says it should be parsed as a function declaration rather than a
> variable declaration to resolve an ambiguous between those two.
> 


There are different opinions about that.
The current Comeau compiler does accept the code.

Here an answer James Kanze on the news group comp.lang.c++

First, there is absolutely no way that proj can be interpreted
as a function declaration; the string literal prevents that,
regardless of anything else.  Second, if "space" is the
name of a type (as it is in your code), »space(V[i])« is a
function declaration in any context that allows function
declarations.  The only contexts which allow declarations
other than at the statement level, however, is as part of other
declarations; the only context in which a function declaration
can be followed by a comma is as a parameter in another function
declaration.  Since in this case, the string literal means that
this statement cannot be a function declaration, »space(V[i])«
cannot be a parameter declaration, and thus, cannot be a
function declaration.  There's no ambiguity.  (This is a
difficult parse, however, since the interpretation here depends
on context.  In something like:
    form proj( space(V[i]) );
»space(V[i])« is a function declaration, and the entire
statement is a function declaration, because there is nothing
which makes it illegal as a function declaration.)

I do remember earlier versions of g++ (2.95.2?) having problems
with this; they didn't consider context to the right of the
expression when making the decision, so something like:
    form proj( space(V[i]), "abc" );
would fail to compile, treating »space(V[i])« as a function
declaration, whereas:
    form proj( "abc", space(V[i]) );
worked, since the preceding string literal had removed the
ambiguity of the context.  Later versions of g++ fixed this.  It
sounds to me like they've reintroduced the bug, and that someone
has decided (on what grounds, I don't know), that it's not a
bug, but a feature.

This is probably a shorter test case:

struct A { A(int, char const*); };
int main() {
  int i = 0, *b = &i;
  A a(int(b[i]), "hello");
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41786