[Bug c++/76995] type-id/expression in cstyle-cast are disambiguated incorrectly

[richard-gccbugzilla at metafoo dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76995

Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard-gccbugzilla@metafoo
                   |                            |.co.uk

--- Comment #2 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
This code is valid, and GCC is incorrect to reject it (as is Clang and EDG, of
course). The expression context

  (T())

is ambiguous: it could either be a C-style cast to the function type 'T()' or a
parenthesized functional cast expression constructing an object of type 'T'. A
correct parser is required to look at what follows the construct to figure out
which of these two cases we're in: if the following tokens form a valid
cast-expression, then it's an (ill-formed) cast to a function type. Otherwise,
it's a parenthesized functional cast.

The following tokens are (args...), which do not form a valid cast-expression,
so the overall expression unambiguously parses the same as 'mytype()(args...)',
rather than as a type cast.


And for the record: I think this language rule is ridiculous. As far as I can
determine, the only cases that result in this ambiguity involve a choice
between a cast to a function type and something else; since a cast to a
function type is not meaningful, we could -- and arguably should -- change the
grammar to treat such cases as the non-cast interpretation. But I think that
argues even more strongly that GCC is wrong to reject this.