CVS difference for ai05s/ai05-0110-1.txt
--- ai05s/ai05-0110-1.txt 2011/02/08 08:21:05 1.8
+++ ai05s/ai05-0110-1.txt 2011/03/05 04:22:53 1.9
@@ -1,4 +1,4 @@
-!standard 12.5(20/2) 10-10-05 AI05-0110-1/01
+!standard 12.5(20/2) 11-03-03 AI05-0110-1/02
!standard 12.5.1(21/3)
!class binding interpretation 08-08-08
!status work item 08-08-08
@@ -6,10 +6,11 @@
!priority Low
!difficulty Hard
!qualifier Omission
-!subject Characteristics of generic formal derived type are not inherited
+!subject Inheritance of characteristics of generic formal derived types
!summary
+The characteristics of generic formal derived types are inherited.
The model of inheritance for generic formal derived types is the same as that for
a derived type declaration.
@@ -46,42 +47,74 @@
!wording
- In 3.4(7), italize "characteristics", add it to the index (in addition
- to the definition in 7.3).
+ In 3.4(7) replace
+ The characteristics of the derived type are defined as follows:
- Replace 12.5.1(20/2)
- If the ancestor type is a composite type that is not an array type,
- the formal type inherits components from the ancestor type
- (including discriminants if a new discriminant_part is not
- specified), as for a derived type defined by a
- derived_type_definition (see 3.4 and 7.3.1).
+ with
+ The *characteristics* and implicitly declared primitive subprograms
+ of the derived type are defined as follows:
+ AARM note:
+ The characteristics of a type do not include its primitive
+ subprograms. The rules governing availability/visibility and
+ inheritance of characteristics are separate from those
+ for primitive subprograms.
+
+ [Add "characteristics" to the index for this paragraph, in addition to
+ the definition in 7.3.]
+
+ Replace 7.3(16/2)
+
+ A private extension inherits components (including discriminants
+ unless there is a new discriminant_part specified) and user-defined
+ primitive subprograms from its ancestor type and its progenitor
+ types (if any), in the same way that a record extension inherits
+ components and user-defined primitive subprograms from its parent
+ type and its progenitor types (see 3.4).
+
with
- The characteristics of a formal derived type are defined
- as for a derived type defined by a derived_type_definition
- (see 3.4 and 7.3.1).
+ A private extension inherits characteristics (including
+ components, but excluding discriminants if there is a
+ new discriminant_part specified) and primitive subprograms
+ from its ancestor type and its progenitor types (if any), in the
+ same way that a record extension inherits characteristics
+ and primitive subprograms from its parent type and its progenitor
+ types (see 3.4).
- AARM note:
- Note that this includes the implicit declarations of inherited
- primitive subprograms.
+ Replace 12.5.1(20/2)
+ If the ancestor type is a composite type that is not an array type,
+ the formal type inherits components from the ancestor type
+ (including discriminants if a new discriminant_part is not
+ specified), as for a derived type defined by a
+ derived_type_definition (see 3.4 and 7.3.1).
+ with
+
+ A formal derived type inherits characteristics (including
+ components, but excluding discriminants if there is a
+ new discriminant_part specified) and primitive subprograms
+ from its ancestor type and its progenitor types (if any), in the
+ same way that a record extension inherits characteristics
+ and primitive subprograms from its parent type and its progenitor
+ types (see 3.4).
+
Replace the beginning of 12.5.1 (21/3)
For a formal derived type, the predefined operators and inherited
- user-defined subprograms are determined by the ancestor type and any
- progenitor types, and are implicitly declared at the earliest place,
- if any, immediately within the declarative region in which within
- the immediate scope of the formal type is declared, where the
- corresponding primitive subprogram of the ancestor or progenitor is
- visible (see 7.3.1). In an instance, the copy of such an implicit
- declaration declares ...
+ user-defined subprograms are determined by the ancestor type and
+ any progenitor types, and are implicitly declared at the earliest
+ place, if any, immediately within the declarative region in which
+ within the immediate scope of the formal type is declared, where
+ the corresponding primitive subprogram of the ancestor or
+ progenitor is visible (see 7.3.1). In an instance, the copy of
+ such an implicit declaration declares ...
with
- In an instance, the copy of an implicit declaration of an
- inherited primitive subprogram of a formal derived type declares ...
+ In an instance, the copy of an implicit declaration of a
+ primitive subprogram of a formal derived type declares ...
!discussion
@@ -779,5 +812,79 @@
Comments?
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, March 3, 2010 2:45 PM
+
+Here is proposed wording for AI05-0110 (part of my Tampa homework).
+
+This includes changes to 3.4 making it clear that the characteristics of a type do not
+include its primitive subprograms.
+
+Thanks to Tuck and Randy for their review and suggestions.
+
+[Following is the wording of version /02.]
+
+Note 12.5.1(21/3) wording change from previous version of this AI - it used to say
+"implicit declaration of an inherited primitive subprogram", which excluded
+implicitly-declared-but-not-inherited predefined subps (e.g., "=" for a tagged
+private extension), which seemed wrong.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, March 3, 2010 7:55 PM
+
+I wonder whether predefined operators should be part of the characteristics, while
+the other primitive subprograms are not. Predefined operators "wink" into existence
+whenever we learn more about a type, whereas non-predefined primitive subprograms
+only get implicitly declared at a smaller number of places.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, March 4, 2010 10:19 PM
+
+> I wonder whether predefined operators should be part of the
+> characteristics, while the other primitive subprograms are not.
+> Predefined operators "wink" into existence whenever we learn more
+> about a type, whereas non-predefined primitive subprograms only get
+> implicitly declared at a smaller number of places.
+
+I suspect that we'll have trouble either way. :-)
+
+Predefined operators can be overridden, and that is the reason (at least as I
+understand it) that we don't want to include subprograms as "characteristics".
+
+So I think it probably is better to rely on the existing wording (which we have
+some reason to presume is correct for such operators) rather than hope that the
+"characteristics" wording is correct (this being a new use for it).
+
+Specifically, 7.3.1(3/3) has specific wording for where predefined operators are
+declared (separately from "characteristics"). So long as we keep in mind that they
+are not characteristics (and have to be mentioned explicitly), I think we are OK
+-- and I for one have no interest in introducing new bugs here which we surely will
+have to fix.
+
+So the only question is whether Steve's new wording adequately includes them.
+
+In 7.3(16):
+
+ A private extension inherits characteristics (including
+ components, but excluding discriminants if there is a
+ new discriminant_part specified) and primitive subprograms
+ from its ancestor type and its progenitor types (if any), in the
+ same way that a record extension inherits characteristics
+ and primitive subprograms from its parent type and its progenitor
+ types (see 3.4).
+
+"primitive subprograms" does include predefined operators. I'd be a bit happier if
+we mentioned them by parenthetical remark, but it is not critical. That is,
+"... and primitive subprograms {(including predefined operators)} from its ancestor
+type and ...".
+
+12.5.1(20/2) is essentially the same, and I'd have the same suggestion for it.
****************************************************************
Questions? Ask the ACAA Technical Agent