Public Comment Number PC-UK0016 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-30 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: 6.1.1 Title: eliminate conditional keywords Detailed description: 6.1.1 makes the keywords "complex" and "imaginary" only be "reserved" if the header is included. This is a problem for two different reasons. Firstly, cautious programmers will assume that the keywords might be needed at some later date, for example by a system header that they have no control over. Therefore they will have to play safe and not use them. The less cautious may use them, and then be burnt later when such a change outside their control happens. Both cases bring the Standard into disrepute. Seeing that the decision has already been made to introduce new keywords, there is little benefit in this approach unless it is going to be more radical (for example, making complex types be unavailable on freestanding implementations). And, even so, there are better approaches. Secondly, the term "reserved" is being misused. This term (see 7.1.3) means that an identifier may not be redeclared. Keywords are not identifiers, and thus reservation is nonsense. In any case, the syntax does not allow a keyword to be used as if it were an identifier. Three alternatives are given here; my preference is for the third. Alternative 1: delete 6.1.1 paragraph 2. Alternative 2: if it is still viewed as desirable to make the names "complex" and "imaginary" available to programmers not using , then: * Change the keywords in 6.1.1 to __complex and __imaginary. * Add to 7.8 a new paragraph 4: The macro /complex/ is defined to be /__complex/. If and only if the macro /_Imaginary_I/ is defined, then the macro /imaginary/ is defined to be /__imaginary/. Notwithstanding the provisions of subclause 7.1.3, it is permitted to undefine the macros /complex/ and /imaginary/. Alternative 3: since complex types are basic to the language while imaginary types are an extension: * Change the keyword imaginary in 6.1.1 to __imaginary. * Add to 7.8 a new paragraph 4: If and only if the macro /_Imaginary_I/ is defined, then the macro /imaginary/ is defined to be /__imaginary/. Notwithstanding the provisions of subclause 7.1.3, it is permitted to undefine the macro /imaginary/.