Created on 2008-03-21.00:00:00 last changed 161 months ago
[Voted into the WP at the September, 2008 meeting.]
Proposed resolution (March, 2008):
Delete the indicated words from 18.104.22.168 [expr.dynamic.cast] paragraph 1:
Types shall not be defined in a dynamic_cast....
Delete the indicated words from 22.214.171.124 [expr.typeid] paragraph 4:
Types shall not be defined in the type-id....
Delete the indicated words from 126.96.36.199 [expr.static.cast] paragraph 1:
Types shall not be defined in a static_cast....
Delete the indicated words from 188.8.131.52 [expr.reinterpret.cast] paragraph 1:
Types shall not be defined in a reinterpret_cast....
Delete the indicated words from 184.108.40.206 [expr.const.cast] paragraph 1:
Types shall not be defined in a const_cast....
Delete paragraph 5 of 220.127.116.11 [expr.sizeof]:
Types shall not be defined in a sizeof expression.
Delete paragraph 5 of 18.104.22.168 [expr.new]:
The type-specifier-seq shall not contain class declarations, or enumeration declarations.
Delete paragraph 4 of 22.214.171.124 [expr.alignof]:
A type shall not be defined in an alignof expression.
Delete paragraph 3 of 7.6.3 [expr.cast]:
Types shall not be defined in casts.
Delete the indicated words from 8.5 [stmt.select] paragraph 2:
The type-specifier-seq shall not contain typedef and shall not declare a new class or enumeration....
Add the indicated words to 9.2.9 [dcl.type] paragraph 3:
At least one type-specifier that is not a cv-qualifier is required in a declaration unless it declares a constructor, destructor or conversion function. [Footnote: ... ]
Delete the indicated words from 126.96.36.199 [class.conv.fct] paragraph 1:
Classes, enumerations, and typedef-names shall not be declared in the type-specifier-seq....
Delete the indicated words from 14.4 [except.handle] paragraph 1:
Types shall not be defined in an exception-declaration.
Delete paragraph 6 of 14.5 [except.spec]:
Types shall not be defined in exception-specifications.
[Drafting note: no changes are required to 7.5.5 [expr.prim.lambda], 9.2.4 [dcl.typedef], 9.12.2 [dcl.align], 9.7.1 [dcl.enum], 188.8.131.52 [dcl.fct], 13.2 [temp.param], or 13.3 [temp.names].]
The restrictions on declaring and/or defining classes inside type-specifier-seqs and type-ids are inconsistent throughout the Standard. This is probably due to the fact that nearly all of the sections that deal with them attempt to state the restriction afresh. There are three cases:
184.108.40.206 [expr.new], 8.5 [stmt.select], and 220.127.116.11 [class.conv.fct] prohibit “declarations” of classes and enumerations. That means that
while (struct C* p = 0) ;
is ill-formed unless a prior declaration of C has been seen. These appear to be cases that should have been fixed by issue 379, changing “class declaration” to “class definition,” but were overlooked.
7.5.5 [expr.prim.lambda], Clause 9 [dcl.dcl], and 18.104.22.168 [dcl.fct] (late-specified return types) do not contain any restriction at all.
All the remaining cases prohibit “type definitions,” apparently referring to classes and enumerations.
Add something like, “A class or enumeration shall not be defined in a type-specifier-seq or in a type-id,” to a single place in the Standard and remove all other mentions of that restriction (allowing declarations via elaborated-type-specifier).
An alias-declaration is just a different syntax for a typedef declaration, which allows definitions of a class in the type; I would expect the same to be true of an alias-declaration. I don't have any particularly strong attachment to allowing a class definition in an alias-declaration. My only concern is introducing an irregularity into what are currently exact-match semantics with typedefs.
There's a parallel restriction in many (but not all?) of these places on typedef declarations.
Those are redundant, as typedef is not a type-specifier, and should be removed as well.
|2008-10-05 00:00:00||admin||set||messages: + msg1821|
|2008-10-05 00:00:00||admin||set||status: ready -> cd1|
|2008-06-29 00:00:00||admin||set||status: open -> ready|
|2008-05-18 00:00:00||admin||set||messages: + msg1668|