!standard 08.03 (09-10) 99-10-07 AI95-00044/06 !standard 08.03 (26) !class binding interpretation 95-06-25 !status Corrigendum 2000 99-07-20 !status WG9 approved 96-12-07 !status ARG approved 11-1-0 96-10-07 !status work item (letter ballot requested and failed) 96-09-15 !status ARG approved 8-0-0 96-06-17 !status work item 95-11-01 !status received 95-06-25 !reference AI95-00150 !priority High !difficulty Medium !qualifier Omission !subject Overriding by implicit declarations !summary For an explicit declaration of "=", the corresponding "/=" that is implicitly declared (if any) overrides the predefined "/=" (if any). The implicit declaration of a statement_identifier overrides the implicit declaration of an inherited subprogram with the same identifier. !question 8.3(9-13) does not cover the case of an implicitly declared "/=" that corresponds to an explicitly declared "=" operator. Is it the intent that such a "/=" operator overrides a predefined "/="? (Yes.) These paragraphs also fail to cover the case of a statement_identifier. Is it the intent that a statement_identifier overrides an inherited subprogram with the same name? (Yes.) !recommendation (See summary.) !wording !discussion For the "/=" issue, clearly it would be confusing if the predefined "/=" were visible instead of the one corresponding to the user-defined "=". For the statement_identifier issue, clearly the statement_identifier should override, because although the declaration is implicit, the statement_identifier itself is sitting right there in the code. Furthermore, we don't want to have a case where a non-overloadable declaration is overloaded, which would be the case if the statement_identifier did not hide, and both were visible. This interpretation is also necessary for upward compatibility, because in Ada 83, a statement_identifier hides an inherited subprogram. This is illustrated by validation test B83033B. In retrospect, it was probably a mistake to base the definition of overriding on whether or not a declaration is implicit. A better model might be as follows: The implicit declaration of a predefined operator or an inherited subprogram is an "overridable declaration". [Only overridable declarations may be overridden.] If two or more homographs occur immediately within the same declarative region, then: 1) at most one of them is allowed to be a non-overridable declaration; 2) a non-overridable declaration overrides an overridable declaration, independent of which comes first; 3) an inherited subprogram overrides a predefined operator, except for equality of tagged types, where the reverse applies; 4) for those pairs for which (1) to (3) don't apply, a later overridable declaration overrides an earlier one. !corrigendum 8.03(9) @drepl Two homographs are not generally allowed immediately within the same declarative region unless one @i the other (see Legality Rules below). A declaration overrides another homograph that occurs immediately within the same declarative region in the following cases: @dby Two homographs are not generally allowed immediately within the same declarative region unless one @i the other (see Legality Rules below). The only declarations that are @i are the implicit declarations for predefined operators and inherited primitive subprograms. A declaration overrides another homograph that occurs immediately within the same declarative region in the following cases: !corrigendum 8.03(10) @drepl @xbullet @dby @xbullet !corrigendum 8.03(26) @drepl An explicit declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the explicit declaration. Similarly, the @fa for a @fa is illegal if it mentions (in a @fa) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. @dby A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. Similarly, the @fa for a @fa is illegal if it mentions (in a @fa) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. !ACATS test For the first part of this ruling, tests C67002A.Ada, C67002D.Ada, etc. check the overriding of "=". For the second part of this ruling, test B83033B.Ada checks that the rule is enforced. !appendix !section 8.3(9) !section 6.6(6) !subject Case of Overriding Missing in 8.3 ? !reference AARM-8.3(9-13);6.0 !reference AARM-6.6(6);6.0 !from Jesper Joergensen 95-04-28 !reference as: 95-5130.a Jesper Joergensen 95-4-28>> !discussion Section 6.6(6) says that a (explicit?) declaration of "=" implicitly declares a "/=". I guess that this "/=" (although it is implictly declared) overrides the predefined "/=" if such a one exists and is type conformant, but this case is not covered by any of the paragraphs 8.3(9-13) because the implicit "/=" is neither predefined nor inherited. Is this assumption correct? /Jesper **************************************************************** !section 8.3(10) !subject Does a label hide an inherited subprogram? !reference RM95-8.3(10) !from Bob Duff !reference as: 95-5214.e Robert A Duff 95-7-8>> !discussion I'm submitting this on behalf of Tucker. 8.3(10-13) does not mention implicit declarations of labels, which seems to imply that a label does not hide an inherited subprogram. In Ada 83, however, a label hides an inherited subprogram. This is illustrated by ACVC b83033b. Is this upward incompatibility intended? I think not. Clearly, a label ought to hide an inherited subprogram, since although the label's declaration is implicit, the label itself is sitting right there in the code. Furthermore, we don't want to have a case where a non-overloadable declaration is overloaded, which would be the case if the label did not hide, and both were visible. The same issue applies to block and loop names. The fix would be to add "(or the implicit declaration of a statement_identifier)" to 8.3(10) before "overrides", or else add a sentence, "Similarly, the implicit declaration of a statement_identifier overrides an implicit ...[duplicate rest of 8.3(10)]". **************************************************************** !section 8.3(9) !subject Implicit decls and overriding !reference 95-5206.a Robert A Duff 95-6-29 (AI95-0044/00) !reference 95-5130.a Jesper Joergensen 95-4-28 !reference AARM-8.3(9-13);6.0 !reference AARM-6.6(6);6.0 !reference 95-5214.e Robert A Duff 95-7-8 !from Tucker Taft 95-08-04 !reference as: 95-5251.a Tucker Taft 95-8-4>> !discussion There have been two recent comments regarding overriding and implicit declarations. It seems like it is time to admit that making a link between implicit vs. explicit declarations and legality of overriding was a mistake in RM95. Here is the first one: > !standard 08.03 (09) 95-06-25 AI95-00044/00 > !class binding interpretation 95-06-25 > !status received 95-06-25 > !subject Case of Overriding Missing in 8.3 ? > > !summary 95-06-25 > > For an explicit declaration of "=", the corresponding "/=" that is > implicitly declared (if any) overrides the predefined "/=" (if any). The second one, in 95-5214.e, was talking about the implicit declaration of a label overriding an inherited subprogram. We struggled many times with the fact that the overriding rules were related to whether or not a declaration was implicit. I believe now that the "implicitness" should be irrelevant. The new model I would recommend is as follows: Define "overridable declaration" as a declaration of a predefined operator or an inherited subprogram. (All such declarations are implicit, for what that's worth.) Only overridable declarations may be overridden. To be precise: If there are two or more declarations that occur immediately within the same declarative region which are homographs, then for these homographs: 1) at most one of them is allowed to be a non-overridable declaration; 2) a non-overridable declaration overrides an overridable declaration, independent of which comes first; 3) an inherited subprogram overrides a predefined operator, except for equality of tagged types, where the reverse applies; 4) for those pairs for which (1) to (3) don't apply, a later overridable declaration overrides an earlier one. I believe this will solve the above two problems, and eliminate the funny games we have had to play to specify whether a given declaration is implicit or explicit, which are particular confusing when talking about declarations inside of instances, declarations of labels, and declarations of "/=". -Tuck ****************************************************************