Subject: Type-bound assignment/operator ambiguity J3/02-185r2 From: Kurt W. Hirchert (Meeting 161) 17 May 2002 Of the alternative solutions offered in 02-185, alternative 5 would not be my first choice if we were not pressed for time, but it appears to be the only alternative we have a reasonable chance to complete before turning the 007 over to WG5. Although Malcolm has asserted in premeeting e-mail that this alternative already applies, 16.2.3 can be interpreted otherwise, so edits are offered here to reinforce Malcolm's interpretation of this section. While looking at this section, we also found other problems that are addressed in the edits. ===== Edits ===== 75:36+ Add the following paragraphs: Two entities are <> if neither is type compatible with the other. An entity is type, kind, and rank compatible, or <>, with another entity if the first entity is type compatible with the second, the kind type parameters of the first entity have the same values as corresponding kind type parameters of the second, and both entities have the same rank. Two entities are <> if neither is TKR compatible with the other. 397:18 Insert " within a scoping unit" before the first period. 397:22-25 Delete the final two sentences of the paragraph. Add new note following the paragraph: In most scoping units, the possible sources of procedures with a particular generic identifier are the accessible interface blocks and the type-bound generic bindings other than names for the accessible objects in that scoping unit. In a type definition, they are the generic bindings, including those from a parent type. 397:34-36 Completely replace first item in list: (1) there is a non-passed-object dummy argument in one or the other of them such that (a) the number of dummy arguments in one that are nonoptional, are not passed-object, and with which that dummy argument is TKR compatible (5.1.1.8), possibly including that dummy argument itself, exceeds (b) the number of non-passed-object dummy arguments, both optional and nonoptional, in the other that are not TKR incompatible with that dummy argument; [The editor is encouraged to spell "non-passed-object" in whatever way he believes is most appropriate.] [Yes, we really want "not TKR incompatible". That is not equivalent to "TKR compatible".] [it is intended that the word "exceeds" appear at the nesting level of item (1) rather than that of (1)(a).] [During the debate, SG committed to providing text at the next meeting for a note illustrating the application of this rule and the implication of the above comments about "not TKR incompatible".] 397:36+ Insert new item in list: (1+1) both have passed-object dummy arguments and the passed-object dummy arguments are TKR incompatible; or 397:38,398:2 insert "non-passed-object" after "nonoptional" 398:38,39(x2) insert "effective" before "position" 398:1,4 Replace "type incompatible, has different parameters, or has different rank" with "TKR incompatible" [The cumulative effect of the above three edits on 397:38- 398:4 is the following: (a) A nonoptional non-passed-object dummy argument at an effective position such that either the other procedure has no dummy argument at that effective position or the dummy argument at that effective position is TKR incompatible; and (b) A nonoptional non-passed-object dummy argument whose name is such that either the other procedure has no dummy argument with that name or the dummy argument with that name is TKR incompatible. ] 398:5-6 Outdent paragraph one level. (I.e., item (2)(b) ends with the preceding paragraph. This text is merely part of item (2).) 398:7 Delete the existing text (which has moved to 75:36+), and replace it with the following unrelated text: The <> of a dummy argument is its position in the argument list after any passed-object dummy argument has been removed. 398:8 Replace "If" with "Within a scoping unit, if" for consistency with 397:26,30,32. - end -