!standard 3.9.2(10/1) 05-05-05 AI95-00430/01 !class amendment 05-04-18 !status Amendment 200Y 05-05-05 !status ARG Approved 10-0-1 05-04-18 !status work item 05-04-18 !status received 05-04-18 !priority High !difficulty Easy !subject Conventions of inherited subprograms !summary The conventions of inherited dispatching operations are that of the parent or progenitor operations. Overridings of these routines have that convention by default (it can be explicitly given, but if different, the program will be illegal). If a routine overrides multiple inherited operations, they all must have the same convention. !problem 3.9.2(10/1) does not say what happens when a type inherits routines with different conventions. In addition, an unfriendly reading of 3.9.2(10/1) would suggest that the convention of an inherited subprogram is fixed such that even a pragma convention would be ignored. !proposal (See summary.) !wording Replace the third sentences of 3.9.2(10) by: The convention of an inherited dispatching operation is the convention of the corresponding primitive operation of the parent or progenitor type. The default convention of a dispatching operation that overrides an inherited primitive operation is the convention of the inherited operation; if the operation overrides multiple inherited operations, then they shall all have the same convention. !discussion The requirement that an overriding subprogram is subtype conformant (which requires matching conventions) provides some relief. But it is better to say the obvious up front. !example (See discussion.) !corrigendum 3.9.2(10) @drepl In the declaration of a dispatching operation of a tagged type, everywhere a subtype of the tagged type appears as a subtype of the profile (see 6.1), it shall statically match the first subtype of the tagged type. If the dispatching operation overrides an inherited subprogram, it shall be subtype conformant with the inherited subprogram. The convention of an inherited or overriding dispatching operation is the convention of the corresponding primitive operation of the parent type. An explicitly declared dispatching operation shall not be of convention Intrinsic. @dby In the declaration of a dispatching operation of a tagged type, everywhere a subtype of the tagged type appears as a subtype of the profile (see 6.1), it shall statically match the first subtype of the tagged type. If the dispatching operation overrides an inherited subprogram, it shall be subtype conformant with the inherited subprogram. The convention of an inherited dispatching operation is the convention of the corresponding primitive operation of the parent or progenitor type. The default convention of a dispatching operation that overrides an inherited primitive operation is the convention of the inherited operation; if the operation overrides multiple inherited operations, then they shall all have the same convention. An explicitly declared dispatching operation shall not be of convention Intrinsic. !ACATS test !appendix From: Robert A. Duff Sent: Saturday, December 24, 2005 8:33 AM It seems like AI-430 should be a binding interpretation, and should apply to Ada 95, because the second paragraph of the !problem is pointing out a bug to fix. (The first paragraph of the !problem applies only to Ada 2005.) Here's the !problem part: 3.9.2(10/1) does not say what happens when a type inherits routines with different conventions. In addition, an unfriendly reading of 3.9.2(10/1) would suggest that the convention of an inherited subprogram is fixed such that even a pragma convention would be ignored. ************************************************************* From: Pascal Leroy Sent: Tuesday, January 3, 2006 2:08 AM As you point out, the part of the AI that deals with multiple routines with different conventions is specific to Ada 2005. Therefore, this AI cannot be a binding interpretation: we wouldn't want to insert in the Ada 95 RM words that would seem to imply that you can inherit several routines with different conventions. If would be possible to split this AI into a BI (addressing the second part of the problem) and an Amendment AI (addressing the first part) but that would be a considerable loss of energy if you ask me. The only interesting part of the AI is the Ada 2005 part. The stuff that pertains to Ada 95 is merely a clarification, and it's hard to imagine an implementation doing something different anyway. ************************************************************* From: Robert Dewar Sent: Tuesday, January 3, 2006 7:14 AM Well speaking for GNAT, this definitely required a new check to give the desired diagnostic. There was no basis for such a diagnostic previously. And of course we retrofitted this to Ada 95 mode. ************************************************************* From: Robert Dewar Sent: Tuesday, January 3, 2006 7:49 AM I would just add a note to this effect to the AI making it clear that this part is something that applies to Ada 95. Given that some members of the ARG have taken such a fierce (to me) line on not fixing obvious errors in Ada 95, we don't want this to be another misunderstanding :-) *************************************************************