Subject: US Item 2.7 J3/03-140 From: Kurt W. Hirchert (Meeting 164) 10 Mar 2003 Item 2.7 originated as item 4 from my personal comments (J3/02-314). Had the draft actually said what I thought it did, it would have indeed been a serious problem, but Aleksander Donev has pointed out to me that I was misreading 5.1.1.8 and that the existing text does most of what I was proposing to do. Thus, instead of the major edit I was expecting to have to produce, there remain on a small number of more minor repairs and cleanups. The largest of these is addressed by my suggested edits for Item 2.1 in J3/03-139. The remainder are presented below with comments to explain their origin. ===== Edits ===== 1. 480:18,21,22,30,33-35 Change "TYPE" to "CLASS". {* After recognizing my misinterpretation of 5.1.1.8, I was concerned that this mistinterpretation might have caused other problems during the period I held it. In particular, I was concerned about the revision of the rules in 16.2.3. After reviewing them, my conclusion was that the only change needed in those rules was to read them with the correct interpretation of 5.1.1.8 in mind. However, I was not so fortuitous with the notes in C.11.2 illustrating those rules -- two of the examples were flawed by my misconception. The above change corrects those flaws. *} 2. 266:42 Insert ", except for components of an object of derived type for which default initialization has been specified" before the ".". {* This is intended to make this statement consistent with statement on 79:18-20. *} 3. 265:6-10 Replace with <<<<< If a dummy argument is neither allocatable nor a pointer, it shall be type compatible (5.1.1.8) with the associated actual argument. If a dummy argument is allocatable or a pointer, the associated actual argument shall be polymorphic if and only if the dummy argument is polymorphic, and type of the actual argument shall be the same as the type of the dummy argument. >>>>> {* There were several things I did not like about the previous version of these rules, but one particular aspect convinced me that they had to be changed: The old version makes the rules in 16.2.3 inadequate to prevent ambiguous generics. In particular, it exempts INTENT(OUT) dummy arguments that are allocatable or a pointer from the usual type compatibility rules. 16.2.3 depends on the usual type compatibility to ensure unambiguous resolution. For example, if our generic consists of two procedures, each with a single argument, one CLASS(apple) and one CLASS(pear), 16.2.3 finds these to be distinguishable. However, if they are INTENT(OUT) pointers, then both could be associated with a CLASS(fruit) pointer actual argument, thus making them ambiguous. There are other possible repairs, but this seemed the simplest. *} - end - -- Kurt W Hirchert hirchert@atmos.uiuc.edu UIUC Department of Atmospheric Sciences +1-217-265-0327