CVS difference for ais/ai-00401.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00401.txt

--- ais/ai-00401.txt	2005/01/28 02:10:51	1.2
+++ ais/ai-00401.txt	2005/04/13 05:37:22	1.3
@@ -1,5 +1,26 @@
-!standard 3.4(1)                                      05-01-27  AI95-00401/01
+!standard 3.4(01)                                      05-03-01  AI95-00401/02
+!standard 3.4(03)
+!standard 3.4(05)
+!standard 3.4(08)
+!standard 3.4(17)
+!standard 3.4(18)
+!standard 3.4(22)
+!standard 3.4(23)
+!standard 3.4(23.1)
+!standard 3.4(27)
+!standard 3.4(35)
+!standard 3.4.1(02)
+!standard 7.3(16)
+!standard 7.3(20)
+!standard 9.1(9.1)
+!standard 9.4(11)
+!standard 12.5.1(05)
+!standard 12.5.1(15)
+!standard 12.5.1(21)
+!standard 12.5.5(04)
 !class amendment 05-01-25
+!status Amendment 200Y 05-03-01
+!status ARG Approved 7-0-3  05-02-13
 !status work item 05-01-25
 !status received 05-01-25
 !priority High
@@ -52,10 +73,9 @@
 characteristics are derived from those of a parent type{, and possibly from
 progenitor types}.
 
+Change 3.4(3) to read:
 
-Change 3.4(3/2) to read:
-
-An interface_subtype_indication in an interface_list defines a *progenitor
+An interface_subtype_mark in an interface_list names a *progenitor
 subtype*; its type is the progenitor type.
 
 The parent_subtype_indication defines the parent subtype; its type is the
@@ -72,7 +92,7 @@
 
 Change 3.4(8) to read:
 
-Each class of types that includes the parent type {or progenitor type} also
+Each class of types that includes the parent type {or a progenitor type} also
 includes the derived type.
 
 
@@ -102,7 +122,7 @@
 derived type is defined as follows:
 
 
-Change 3.4(21) to read:
+Change 3.4(22) to read:
 
 The same formal parameters have default_expressions in the profile of the
 inherited subprogram. Any type mismatch due to the systematic replacement of
@@ -116,20 +136,14 @@
 place of the derived_type_definition, then the corresponding inherited
 subprogram is implicitly declared immediately after the derived_type_definition.
 Otherwise, the inherited subprogram is implicitly declared later or not at all,
-as explained in 7.3.1{; this can never happen for subprograms inherited from
-interfaces}.
-
-
-Delete 3.4(23.1/2).
+as explained in 7.3.1.
 
 
-Insert before 3.4(26):
+Delete the paragraph added after 3.4(23) by AI95-00251.
 
-The elaboration of an interface_list has no effect.
 
+Change 3.4(27) to read (this includes the changes of AI-391):
 
-Change 3.4(27/2) to read:
-
 For the execution of a call on an inherited subprogram, a call on the
 corresponding primitive subprogram of the parent {or progenitor} type is
 performed; the normal conversion of each actual parameter to the subtype of the
@@ -139,17 +153,17 @@
 converted to the derived type, or in the case of a null extension, extended to
 the derived type using the equivalent of an extension_aggregate with the
 original result as the ancestor_part and null record as the
-record_component_association_list
+record_component_association_list.
 
 
-Change 3.4(35.1/2) to read:
+Change the paragraph added after 3.4(35) by AI95-00251 to read:
 
 An interface type which has a {progenitor type} "is derived from" that type,
 and therefore is a derived type. A derived_type_definition, however, never
 defines an interface type.
 
 
-Change the second sentence of 3.4.1(2/2) to read:
+Change the second sentence of 3.4.1(2) as modified by AI95-00251 to read:
 
 A derived type, interface type, type extension, task type, protected type, or
 formal derived type is also derived from each of its progenitor types, if any.
@@ -173,11 +187,11 @@
 from which the record extension is descended.
 
 
-Delete 9.1(9.2/2).
+Delete the first paragraph added after 9.1(9.1) by AI95-00345.
 
 
-Delete the last sentence of 9.4(11/2). (That, is revert to the original wording
-of RM95.)
+Delete the sentence added to 9.4(11) by AI95-00345. (That, is revert to the
+original wording of RM95.)
 
 
 Change 12.5.1(5) to read:
@@ -191,16 +205,16 @@
 abstract shall appear only if the ancestor type is a tagged type.
 
 
-Change 12.5.1(15.1/2) to read:
+Change the paragraph added after 12.5.1(5) by AI95-00251 to read:
 
 The actual type for a generic formal derived type shall be a descendant of
 every {progenitor} of the formal type.
 
 
-Change 12.5.1(21/2) to read:
+Change 12.5.1(21) to read:
 
 For a formal derived type, the predefined operators and inherited user-defined
-subprograms are determined by the ancestor type {and the progenitor type}, and
+subprograms are determined by the ancestor type {and the progenitor types}, and
 are implicitly declared at the earliest place, if any, immediately within the
 declarative region in which the formal type is declared , where the
 corresponding primitive subprogram of the ancestor {or progenitor} is visible
@@ -216,7 +230,7 @@
 corresponding to the actual type.
 
 
-Change 12.5.5(4/2) to read:
+Change 12.5.5(4) (a section introduced by AI95-00251) to read:
 
 The actual type shall be a descendant of every {progenitor} of the formal type.
 
@@ -226,8 +240,364 @@
 
 !example
 
+!corrigendum 3.4(01)
+
+@drepl
+A @fa<derived_type_definition> defines a new type (and its first subtype) whose characteristics are @i<derived> from those of a @i<parent type>.
+@dby
+A @fa<derived_type_definition> defines a new type (and its first subtype) whose characteristics are @i<derived> from those of a @i<parent type>, and possibly from @i<progenitor types>.
+
+!corrigendum 3.4(03)
+
+@drepl
+The @i<parent>@fa<_subtype_indication> defines the @i<parent subtype>; its type
+is the parent type.
+@dby
+An @i<interface>@fa<_subtype_mark> in an @fa<interface_list> names a
+@i<progenitor subtype>; its type is the progenitor type. The
+@i<parent>@fa<_subtype_indication> defines @i<the parent subtype>; its type is
+the parent type.
+
+A derived type has one parent type and zero or more progenitor types.
+
+!corrigendum 3.4(05)
+
+@drepl
+If there is a @fa<record_extension_part>, the derived type is called a
+@i<record extension> of the parent type. A @fa<record_extension_part> shall be
+provided if and only if the parent type is a tagged type.
+@dby
+If there is a @fa<record_extension_part>, the derived type is called a
+@i<record extension> of the parent type. A @fa<record_extension_part> (and an
+@fa<interface_list>) shall be provided if and only if the parent type is a
+tagged type.
+
+!corrigendum 3.4(08)
+
+@drepl
+@xbullet<Each class of types that includes the parent type also includes the
+derived type.>
+@dby
+@xbullet<Each class of types that includes the parent type or a progenitor type
+also includes the derived type.>
+
+!corrigendum 3.4(17)
+
+@drepl
+@xbullet<For each user-defined primitive subprogram (other than a user-defined
+equality operator -- see below) of the parent type that already exists at the
+place of the @fa<derived_type_definition>, there exists a corresponding
+@i<inherited> primitive subprogram of the derived type with the same defining
+name. Primitive user-defined equality operators of the parent type are also
+inherited by the derived type, except when the derived type is a nonlimited
+record extension, and the inherited operator would have a profile that is type
+conformant with the profile of the corresponding predefined equality operator;
+in this case, the user-defined equality operator is not inherited, but is
+rather incorporated into the implementation of the predefined equality operator
+of the record extension (see 4.5.2).>
+@dby
+@xbullet<For each user-defined primitive subprogram (other than a user-defined
+equality operator -- see below) of the parent type or of a progenitor type that
+already exists at the place of the @fa<derived_type_definition>, there exists a
+corresponding @i<inherited> primitive subprogram of the derived type with the
+same defining name. Primitive user-defined equality operators of the parent
+type are also inherited by the derived type, except when the derived type is a
+nonlimited record extension, and the inherited operator would have a profile
+that is type conformant with the profile of the corresponding predefined
+equality operator; in this case, the user-defined equality operator is not
+inherited, but is rather incorporated into the implementation of the predefined
+equality operator of the record extension (see 4.5.2).>
+
+!corrigendum 3.4(18)
+
+@drepl
+The profile of an inherited subprogram (including an inherited enumeration
+literal) is obtained from the profile of the corresponding (user-defined)
+primitive subprogram of the parent type, after systematic replacement of each
+subtype of its profile (see 6.1) that is of the parent type with a
+@i<corresponding subtype> of the derived type. For a given subtype of the
+parent type, the corresponding subtype of the derived type is defined as
+follows:
+@dby
+The profile of an inherited subprogram (including an inherited enumeration
+literal) is obtained from the profile of the corresponding (user-defined)
+primitive subprogram of the parent or progenitor type, after systematic
+replacement of each subtype of its profile (see 6.1) that is of the parent or
+progenitor type with a @i<corresponding subtype> of the derived type. For a
+given subtype of the parent or progenitor type, the corresponding subtype of
+the derived type is defined as follows:
+
+!corrigendum 3.4(22)
+
+@drepl
+The same formal parameters have @fa<default_expression>s in the profile of the
+inherited subprogram. Any type mismatch due to the systematic replacement of
+the parent type by the derived type is handled as part of the normal type
+conversion associated with parameter passing -- see 6.4.1.
+@dby
+The same formal parameters have @fa<default_expression>s in the profile of the
+inherited subprogram. Any type mismatch due to the systematic replacement of
+the parent or progenitor type by the derived type is handled as part of the
+normal type conversion associated with parameter passing -- see 6.4.1.
+
+!corrigendum 3.4(23)
+
+@drepl
+If a primitive subprogram of the parent type is visible at the place of the
+@fa<derived_type_definition>, then the corresponding inherited subprogram is
+implicitly declared immediately after the @fa<derived_type_definition>.
+Otherwise, the inherited subprogram is implicitly declared later or not at all,
+as explained in 7.3.1.
+@dby
+If a primitive subprogram of the parent or progenitor type is visible at the
+place of the @fa<derived_type_definition>, then the corresponding inherited
+subprogram is implicitly declared immediately after the
+@fa<derived_type_definition>. Otherwise, the inherited subprogram is implicitly
+declared later or not at all, as explained in 7.3.1.
+
+!comment the paragraph added by AI-251 is deleted.
+
+!corrigendum 3.4(27)
+
+@drepl
+For the execution of a call on an inherited subprogram, a call on the
+corresponding primitive subprogram of the parent type is performed; the normal
+conversion of each actual parameter to the subtype of the corresponding formal
+parameter (see 6.4.1) performs any necessary type conversion as well. If the
+result type of the inherited subprogram is the derived type, the result of
+calling the parent's subprogram is converted to the derived type.
+@dby
+For the execution of a call on an inherited subprogram, a call on the
+corresponding primitive subprogram of the parent or progenitor type is
+performed; the normal conversion of each actual parameter to the subtype of the
+corresponding formal parameter (see 6.4.1) performs any necessary type
+conversion as well. If the result type of the inherited subprogram is the
+derived type, the result of calling the parent or progenitor's subprogram is
+converted to the derived type, or in the case of a null extension, extended to
+the derived type using the equivalent of an @fa<extension_aggregate> with the
+original result as the @fa<ancestor_part> and @b<null record> as the
+@fa<record_component_association_list>.
+
+!corrigendum 3.4(35)
+
+@dinsa
+@xindent<@s9<17  If the reserved word @b<abstract> is given in the declaration
+of a type, the type is abstract (see 3.9.3).>>
+@dinst
+@xindent<@s9<18  An interface type which has a progenitor type "is derived
+from" that type, and therefore is a derived type. A
+@fa<derived_type_definition>, however, never defines an interface type.>>
+
+!corrigendum 3.4.1(02)
+
+@drepl
+A derived type is @i<derived from> its parent type @i<directly>; it is derived
+@i<indirectly> from any type from which its parent type is derived. The
+derivation class of types for a type @i<T> (also called the class @i<rooted>
+at @i<T>) is the set consisting of @i<T> (the @i<root type> of the class) and
+all types derived from @i<T> (directly or indirectly) plus any associated
+universal or class-wide types (defined below).
+@dby
+A derived type is @i<derived from> its parent type @i<directly>; it is derived
+@i<indirectly> from any type from which its parent type is derived. A derived
+type, interface type, type extension, task type, protected type, or formal
+derived type is also derived from each of its progenitor types, if any. The
+derivation class of types for a type @i<T> (also called the class @i<rooted> at
+@i<T>) is the set consisting of @i<T> (the @i<root type> of the class) and all
+types derived from @i<T> (directly or indirectly) plus any associated universal
+or class-wide types (defined below).
+
+!corrigendum 7.3(16)
+
+@drepl
+A private extension inherits components (including discriminants unless there
+is a new @fa<discriminant_part> specified) and user-defined primitive
+subprograms from its ancestor type, in the same way that a record extension
+inherits components and user-defined primitive subprograms from its parent type
+(see 3.4).
+@dby
+A private extension inherits components (including discriminants unless there
+is a new @fa<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).
+
+!corrigendum 7.3(20)
+
+@dinsa
+@xindent<@s9<7  The ancestor type specified in a
+@fa<private_extension_declaration> and the parent type specified in the
+corresponding declaration of a record extension given in the private part need
+not be the same @emdash the parent type of the full view can be any descendant
+of the ancestor type. In this case, for a primitive subprogram that is
+inherited from the ancestor type and not overridden, the formal parameter names
+and default expressions (if any) come from the corresponding primitive
+subprogram of the specified ancestor type, while the body comes from the
+corresponding primitive subprogram of the parent type of the full view. See
+3.9.2.>>
+@dinst
+@xindent<@s9<8  The progenitor types specified in a
+@fa<private_extension_declaration> and the progenitor types specified in the
+corresponding declaration of a record extension given in the private part need
+not be the same @emdash the only requirement is that the private extension must
+be descended from each interface from which the record extension is
+descended.]}
+
+!corrigendum 9.1(9.1/1)
+
+@dinsa
+For a task declaration without a @fa<task_definition>, a @fa<task_definition>
+without @fa<task_item>s is assumed.
+@dinss
+For a @fa<task_type_declaration>, if the first parameter of a primitive
+inherited subprogram is of the task type or an access parameter designating the
+task type, and there is an @fa<entry_declaration> for a single entry with the
+same identifier within the @fa<task_type_declaration>, having a profile that is
+type conformant with that of the inherited subprogram after omitting this first
+parameter, the inherited subprogram is said to be @i<implemented> by the
+conforming task entry.
+
+@i<@s8<Legality Rules>>
+
+A task declaration requires a completion, which shall be a @fa<task_body>, and
+every @fa<task_body> shall be the completion of some task declaration.
+
+Each @fa<interface_subtype_mark> of an @fa<interface_list> appearing within a
+@fa<task_type_declaration> shall denote a limited interface type that
+is not a protected interface.
+
+For each primitive subprogram inherited by the type declared by a
+@fa<task_type_declaration>, at most one of the following shall apply:
+
+@xbullet<the inherited subprogram shall be overridden with a primitive
+subprogram of the task type, in which case the overriding
+subprogram shall be subtype conformant with the inherited
+subprogram and not abstract; or>
+
+@xbullet<the inherited subprogram is implemented by a single entry of the
+task type; in which case its profile after omitting the first
+parameter shall be subtype conformant with that of the task entry.>
+
+If neither applies, the inherited subprogram shall be a null procedure.
+
+
+!corrigendum 9.4(11)
+
+@dinsa
+A @fa<protected_definition> defines a protected type and its first subtype. The
+list of @fa<protected_operation_declaration>s of a @fa<protected_definition>,
+together with the @fa<known_discriminant_part>, if any, is called the visible
+part of the protected unit. The optional list of
+@fa<protected_element_declaration>s after the reserved word @b<private> is
+called the private part of the protected unit.
+@dinss
+For a @fa<protected_type_declaration>, the first parameter of a primitive
+inherited subprogram is of the protected type or an access parameter
+designating the protected type, and there is a
+@fa<protected_operation_declaration> for a protected subprogram
+or single entry with the same identifier within the
+@fa<protected_type_declaration>, having a profile that is type conformant with
+that of the inherited subprogram after omitting this first parameter, the
+inherited subprogram is said to be @i<implemented> by the conforming
+protected subprogram or entry.
+
+@i<@s8<Legality Rules>>
+
+A protected declaration requires a completion, which shall be a
+@fa<protected_body>, and every @fa<protected_body> shall be the completion of
+some protected declaration.
+
+Each @fa<interface_subtype_mark> of an @fa<interface_list> appearing within a
+@fa<protected_type_declaration> shall denote a limited interface type that
+is not a task interface.
+
+For each primitive subprogram inherited by the type declared by a
+@fa<protected_type_declaration>, at most one of the following shall apply:
+
+@xbullet<the inherited subprogram is overridden with a primitive
+subprogram of the protected type, in which case the overriding
+subprogram shall be subtype conformant with the inherited
+subprogram and not abstract; or>
+
+@xbullet<the inherited subprogram is implemented by a protected
+subprogram or single entry of the protected type,
+in which case its profile after omitting the first parameter
+shall be subtype conformant with that of the protected
+subprogram or entry.>
+
+If neither applies, the inherited subprogram is a null procedure.
+
+If an inherited subprogram is implemented by a protected procedure or
+an entry, then the first parameter of the inherited subprogram shall be
+of mode @b<out> or @b<in out>, or an access-to-variable parameter.
+
+!corrigendum 12.5.1(05)
+
+@drepl
+The @i<ancestor subtype> of a formal derived type is the subtype denoted by the
+@fa<subtype_mark> of the @fa<formal_derived_type_definition>. For a formal
+derived type declaration, the reserved words @b<with private> shall appear if
+and only if the ancestor type is a tagged type; in this case the formal derived
+type is a private extension of the ancestor type and the ancestor shall not be
+a class-wide type. Similarly, the optional reserved word @b<abstract> shall
+appear only if the ancestor type is a tagged type.
+@dby
+The @i<ancestor subtype> of a formal derived type is the subtype denoted by the
+@fa<subtype_mark> of the @fa<formal_derived_type_definition>. For a formal
+derived type declaration, the reserved words @b<with private> shall appear if
+and only if the ancestor type is a tagged type; in this case the formal derived
+type is a private extension of the ancestor type and the ancestor shall not be
+a class-wide type. Similarly, an @fa<interface_list> or the optional reserved
+word @b<abstract> shall appear only if the ancestor type is a tagged type.
+
+The actual type for a generic formal derived type shall be a descendant of
+every progenitor of the formal type.
+
+!corrigendum 12.5.1(21)
+
+@drepl
+For a formal derived type, the predefined operators and inherited user-defined
+subprograms are determined by the ancestor type, and are implicitly declared at
+the earliest place, if any, within the immediate scope of the formal type,
+where the corresponding primitive subprogram of the ancestor is visible (see
+7.3.1). In an instance, the copy of such an implicit declaration declares a
+view of the corresponding primitive subprogram of the ancestor of the formal
+derived type, even if this primitive has been overridden for the actual type.
+When the ancestor of the formal derived type is itself a formal type, the copy
+of the implicit declaration declares a view of the corresponding copied
+operation of the ancestor. In the case of a formal private extension, however,
+the tag of the formal type is that of the actual type, so if the tag in a call
+is statically determined to be that of the formal type, the body executed will
+be that corresponding to the actual type.
+@dby
+For a formal derived type, the predefined operators and inherited user-defined
+subprograms are determined by the ancestor type and the progenitor types, and
+are implicitly declared at the earliest place, if any, immediately within the
+declarative region in which 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
+a view of the corresponding primitive subprogram of the ancestor or progenitor
+of the formal derived type, even if this primitive has been overridden for the
+actual type. When the ancestor or progenitor of the formal derived type is
+itself a formal type, the copy of the implicit declaration declares a view of
+the corresponding copied operation of the ancestor or progenitor. In the case
+of a formal private extension, however, the tag of the formal type is that of
+the actual type, so if the tag in a call is statically determined to be that of
+the formal type, the body executed will be that corresponding to the actual
+type.
+
+!corrigendum 12.5.5(01)
+!comment Just a dummy to trigger a conflict; the wording change is only in
+!commentt paragraph 4.
+
+@drepl
+The actual type shall be a descendant of every ancestor of the formal type.
+@dby
+The actual type shall be a descendant of every progenitor of the formal type.
+
+!example
 
---!corrigendum
+(See AI-251 and AI-345 for examples.)
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent