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.
