J16/97-0099 WG21/N1137 November 11, 1997 J. Stephen Adamczyk jsa@edg.com Core II WP Changes (Morristown) A. Enum overloading 1) In 13.6 [over.built], remove "or enumeration" in paragraphs 19 and 23; change "pointer type" to "pointer or enumeration type" in paragraph 16; change "pointer to member type" to "enumeration or pointer to member type" in paragraph 21. 2) In 13.3.1.2 [over.match.oper], paragraph 3, third bullet, add as fourth sub-bullet: ... , and -- do not have the same parameter type list as any non-template non-member candidate. In 13.6 [over.built], paragraph 2, add at the end inside the note: As described in _over.match.oper_, if there is a user-written candidate with the same name and parameter types as a built-in candidate operator function, the built-in operator function is hidden and is not included in the set of candidate functions. 3) In 13.3.1.2 [over.match.oper], paragraph 3, second bullet, add at the end: However, if no operand has a class type, only those non-member functions in the lookup set that have a first parameter of type T1 or "reference to (possibly cv-qualified) T1", or (if there is a right operand) a second parameter of type T2 or "reference to (possibly cv-qualified) T2" are candidate functions. B. Ambiguous Conversion Sequence 1) In 13.3.3.1 [over.best.ics], paragraph 10, replace If several different sequences of conversions exist that each convert the argument to the parameter type, the implicit conversion sequence is a sequence among these that is not worse than all the rest according to 13.3.3.2 123). If that conversion sequence is not better than all the rest and a function that uses such an implicit conversion sequence is selected as the best viable function, then the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous. with If several different sequences of conversions exist that each convert the argument to the parameter type, the implicit conversion sequence associated with the parameter is the unique conversion sequence designated the /ambiguous conversion sequence/. For the purpose of ranking implicit conversion sequences as described in _over.ics.rank_, the ambiguous conversion sequence is treated as a user-defined sequence that is indistinguishable from any other user-defined conversion sequence *1). If a function that uses the ambiguous conversion sequence is selected as the best viable function, the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous *2). 2) Add a new footnote at the position of the current footnote 123 (indicated as *1 above): The ambiguous conversion sequence is ranked with user-defined conversion sequences because multiple conversion sequences for an argument can exist only if they involve different user-defined conversions. The ambiguous conversion sequence is indistinguishable from any other user-defined conversion sequence because it represents at least two user-defined conversion sequences, each with a different user-defined conversion, and any other user-defined conversion sequence must be indistinguishable from at least one of them. 3) Move the current footnote 123 to the end of the paragraph (indicated as *2 above). C. Quasi-editorial change to initialization rules (Core 866 issue 1) 1) In 8.5 [dcl.init] paragraph 14, bullet 4, replace sub-bullet 3 with the following: Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in _over.match.copy_, and the best one is chosen through overload resolution (_over.match_). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the destination type. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see _class.temporary_, _class.copy_. 2) In that same paragraph, eliminate footnote 89. D. Change in enumeration of applicable conversion functions in copy initialization -- eliminate cv-qualifier restrictions (Core 866 issue 2) 1) In 13.3.1.4 [over.match.copy], paragraph 1 bullet 1, replace Those that are not hidden within S and yield type "cv2 T2", where T2 is the same type as T or is a derived class thereof, and where cv2 is the same cv-qualification as, or lesser cv-qualification than, cv1, are candidate functions. with Those that are not hidden within S and yield a type whose cv-unqualified version is the same type as T or is a derived class thereof are candidate functions. 2) In 13.3.1.5 [over.match.conv], paragraph 1, bullet 1, replace Those that are not hidden within S and yield type "cv2 T" or a type that can be converted to type "cv2 T" via a standard conversion sequence (_over.ics.scs_), for any cv2 that is the same cv- qualification as, or lesser cv-qualification than, cv1, are candi- date functions. Conversion functions that return a nonclass type "cv2 T" are considered to yield cv-unqualified T for this process of selecting candidate functions. with Those that are not hidden within S and yield type T or a type that can be converted to type T via a standard conversion sequence (_over.ics.scs_) are candidate functions. Conversion functions that return a cv-qualified type are considered to yield the cv-unqualified version of that type for this process of selecting candidate functions. (end)