This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 117a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-05-18
Consider:
int x = (int()) + 5;
This is ill-formed, because 9.3.3 [dcl.ambig.res] paragraph 2 specifies:
An ambiguity can arise from the similarity between a function-style cast and a type-id. The resolution is that any construct that could possibly be a type-id in its syntactic context shall be considered a type-id.
and thus int() is interpreted as a type-id instead of as a function-style cast, so this is an ill-formed cast to a function type.
This seems to be the wrong disambiguation for all cases where there is a choice between a C-style cast and a parenthesized expression: in all those cases, the C-style cast interpretation results in a cast to a function type, which is always ill-formed.
Further, there is implementation divergence in the handling of this example:
struct T { int operator++(int); T operator[](int); };
int a = (T()[3])++; // not a cast
EWG 2022-11-11
This is tracked in github issue cplusplus/papers#1376.
Additional notes (May, 2025)
Also consider this example:
(S())[]->A<int>; // OK, constructor call (S())[]->A<int> {return {};}; // error: C-style cast of lambda
Without the suggested simple rule that (T()) is never a conversion to a function type (which is always semantically ill-formed), syntactic disambiguation would require analysis whether the thing after the arrow is a type (i.e. a trailing return type) or an expression (for operator->).