CVS difference for ais/ai-00389.txt

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

--- ais/ai-00389.txt	2004/11/14 06:37:21	1.2
+++ ais/ai-00389.txt	2004/12/09 19:55:38	1.3
@@ -1,5 +1,11 @@
-!standard 4.3.1(8)                                    04-11-11  AI95-00389/02
+!standard 4.3.1(8)                                    04-12-03  AI95-00389/03
+!standard 4.3.1(16)
+!standard 4.3.1(17)
+!standard 4.3.2(4)
+!standard 4.3.2(5)
 !class amendment 04-11-11
+!status Amendment 200Y 04-12-03
+!status ARG Approved 5-0-5  04-11-20
 !status work item 04-11-11
 !status received 04-11-11
 !priority Medium
@@ -10,7 +16,8 @@
 
 An aggregate of a partial view is allowed; such an aggregate must contain
 "others => <>" to default initialize the components only known to the full
-view.
+view. Similarly, aggregates of task types, protected types, and
+private extensions are allowed.
 
 !problem
 
@@ -28,41 +35,48 @@
 
 !proposal
 
-Allow record aggregates to be of a partial view. The needed components still
-are those of the full view, even though the components of the full view
-cannot be named. An aggregate of a partial view must include "others => <>";
-this is needed to avoid any dependence on the components of the full view.
+Allow record aggregates to be of any non-array composite type. For partial
+views, the needed components still are those of the full view, even though the
+components of the full view cannot be named. An aggregate of a partial view
+must include "others => <>"; this is needed to avoid any dependence on the
+components of the full view.
 
 Note that if known discriminants are given for the type, they can be specified
 along with "others => <>".
 
+Similar rules apply to generic formal types that are composite, task types,
+and protected types. We also have similar rules for extension aggregates of
+partial extensions.
+
 !wording
 
 The wording of this AI assumes the wording changes of AI-287 have been applied.
+
+Change 4.3(3):
+
+The expected type for an aggregate shall be a single composite type.
 
-Change 4.3.2(8):
+Change 4.3.1(8):
 
-The expected type for a record_aggregate shall be a single record type, record
-extension, partial view of a type, formal private type, or composite formal
-derived type.
+The expected type for a record_aggregate shall be a single non-array composite
+type.
 
-4.3.2(9) is unchanged. Add additional AARM notes to the end of the paragraph:
+[Note to Gary: "non-array" occurs in normative wording in 4.1.3(7) and
+13.5.2(1); "nonarray" does not occur in the AARM.]
 
+4.3.1(9) is unchanged. Add an additional AARM note to the end of the paragraph:
+
 Ramification: For a partial view, all of the components of the full type
 are needed, even though not all of them can be named in the aggregate. For
 a generic formal type, all of the components of the actual type
 are needed, even though not all of them can be named in the aggregate.
-
-To Be Honest: For a partial view, if the full view of the type is not
-composite, it is thought of as a record containing one component of
-the full type.
 
-Modify the start of 4.3.2(16) to:
+Modify the start of 4.3.1(16) to:
 
 Each record_component_association {other than an OTHERS choice with a <>} shall
 have at least one associated component...
 
-Modify the AARM Note 4.3.2(16.a):
+Modify the AARM Note 4.3.1(16.a):
 These rules apply to an association with an others choice {with an expression}.
 {An others choice with a <> can match a null record type or a null extension.}
 
@@ -73,33 +87,81 @@
 nothing, as it is harmless (by using OTHERS you've turned off completeness
 checking anyway) and useful.]
 
-Add after 4.3.2(17.1): (The new Legality Rule added by AI-287)
+Add after 4.3.1(17.1): (The new Legality Rule added by AI-287)
 
-If the type of the aggregate is a partial view of a type, a formal private
-type, or a composite formal derived type:
-   * The aggregate shall include OTHERS => <>; and
-
-     AARM Note: This is needed to avoid "leaking" information about the
-     full type to the aggregate. Without this rule, if the
-     full type was NULL RECORD, NULL RECORD could be used; and if the
-     full type had only one component, OTHERS => some-expression could be used.
-     That would clearly break privacy. Similar issues apply to formal types;
-     if information about the actual type could be used in the aggregate,
-     we'd have a generic contract issue. Since each component can only occur
-     in a single association, this rule prevents those issues.
-
-   * The type of the aggregate shall not have unknown discriminants.
-
-     AARM Note: Unknown discriminants are often used to prevent uncontrolled
-     initialization of objects, and we don't want to provide an uncontrolled
-     initialization mechanism for such types.
+If the type of the record_aggregate is a partial view of a type, a task type,
+a protected type, a formal private type, or a formal derived type:
+   * The record_component_association_list shall include OTHERS => <>; and
+
+     AARM Note: Reason: For partial views and generic formals, this is needed
+     to avoid "leaking" information about the full type to the aggregate.
+     Without this rule, if the full type was NULL RECORD, NULL RECORD could be
+     used; and if the full type had only one component, OTHERS =>
+     some-expression could be used. That would clearly break privacy. Similar
+     issues apply to formal types; if information about the actual type could
+     be used in the aggregate, we'd have a generic contract issue. Since each
+     component can only occur in a single association, this rule prevents those
+     issues.
+
+     For tasks and protected types, this recognizes that there may be
+     components (such as the lock for a protected type) that are only known
+     to the implementation; these components necessarily have to be given
+     default initialization. For portability, we don't want aggregates to be
+     written that depend on whether the implementation has such components.
+
+   * The type of the record_aggregate shall have known discriminants or be a
+     tagged, task, or protected type that does not have unknown discriminants;
+     and
+
+     AARM Note: Reason: We only want to allow aggregates of partial views when
+     the full type is certain to be composite. Otherwise, we would have
+     anomalies where additional visibility would cause the ability to have
+     aggregates to disappear (if the full type is elementary).
+     That's true if the partial view has known discriminants or is tagged.
+     Task and protected types are also allowed, as they are always composite.
+     We also disallow types with unknown discriminants. Unknown discriminants
+     are often used to prevent uncontrolled initialization of objects, and
+     we don't want to provide an uncontrolled initialization mechanism for
+     such types.
+
+   * The record_component_association_list shall not include a positional
+     component association.
+
+     AARM Note: Reason: Otherwise, positional notation could be used to give
+     associations for components of the full view that are not visible to the
+     aggregate. That would be bad. We disallow positional notation completely
+     to avoid confusion; this shouldn't be a hardship since typically there
+     will be no more than a couple discriminants along with OTHERS => <> in
+     such an aggregate.
+
+Replace "record extension" in 4.3.2(4) to "type extension".
+
+Modify 4.3.2(5):
+
+   If the ancestor_part is a subtype_mark, it shall denote a specific tagged
+   subtype. The type of the extension_aggregate shall be {a descendant of}
+   [derived from] the type of the ancestor_part[, through one or more record
+   extensions (and no private extensions)]. {If the type of the
+   extension_aggregate is derived from the type of the ancestor_part through
+   one or more private extensions, then the record_component_association_list
+   shall include OTHERS => <>, and shall not include a positional component
+   association.}
+
+   AARM Note: Reason: We allow the type of the ancestor_part to be the
+   type itself, so that these are allowed for generic formal derived types,
+   where the actual type might be the same as the ancestor type.
+
+   If the type involves any private extensions, we require the use of
+   OTHERS => <> and disallow positional associations in order to avoid
+   breaking privacy of the extensions. See 4.3.1 for a more complete
+   discussion.
 
 !discussion
 
 This capability is a natural extension to that provided by AI-287. It is
 especially odd that such initializations are allowed in larger aggregates,
-just not for a complete object. For instance, given that Priv is a private
-type:
+just not for a complete object. For instance, given that Priv is a tagged
+private type:
 
     type Wrapper is record
        P : Priv;
@@ -108,34 +170,110 @@
     Obj1 : constant Priv := (others => <>); -- Illegal by AI-287, allowed here.
     Obj2 : constant Wrapper := (others => <>); -- Legal by AI-287.
 
+In order to avoid the anomaly of having an aggregate be legal for a partial
+view but not the full view, aggregates are not allowed for partial views that
+could be completed with an elementary type. Also to avoid that anomaly, we
+have to provide aggregates for task and protected types (as these are composite
+types which otherwise would not have aggregates).
+
+We have to disallow any way to give a component of the full view without naming
+it in one of these new aggregates. To do that, we disallow positional notation,
+and OTHERS => <> is required.
+
+In order to make this work cleanly, we need to define aggregates for (nearly)
+all composite types. Thus, we added aggregates of task and protected types.
+These also always require OTHERS => <>, as a task or protected object usually
+will have implementation-defined components that cannot be named. As with
+partial views, we do not want to expose the actual implementation in an
+aggregate.
 
-We have chosen not to define extension aggregates for partial extensions.
-These would have implementation issues, and for the most part duplicate
-functionality of record aggregates for partial views.
-
-Implementing an extension aggregate of a partial view would require a
-mechanism to default-initialize only the extension part of a type. This would
-be a new capability; while Ada compilers routinely have to default-initialize
-entire objects of a type (optionally with specified discriminants), they don't
-have to do that for a portion of a type (except for constructing the
-default-initialization of a containing type). This would be especially
-messy for type derived from a generic formal derived type, as the details
-of the extension parts would come from the actual type.
-
-Moreover, an extension aggregate of a partial extension using a subtype
-ancestor is identical in meaning to a record aggregate of the same type.
-That is (Some_Parent with others => <>) is just a complicated way to say
-(others => <>), since the Some_Parent part is also default initialized.
-
-We do lose the capability to initialize the parent part with an expression
-for a partial view, but this ability doesn't seem to be worth the
-implementation burden.
+We also define similar capabilities and restrictions for extension aggregates
+when one or more private extensions is involved.
 
 !example
 
 (See discussion.)
+
+!corrigendum 4.3(3)
 
---!corrigendum
+@drepl
+The expected type for an @fa<aggregate> shall be a single nonlimited array
+type, record type, or record extension.
+@dby
+The expected type for an @fa<aggregate> shall be a single composite type.
+
+!corrigendum 4.3.1(8)
+
+@drepl
+The expected type for a @fa<record_aggregate> shall be a single nonlimited
+record type or record extension.
+@dby
+The expected type for a @fa<record_aggregate> shall be a single non-array
+composite type.
+
+!corrigendum 4.3.1(16)
+
+@drepl
+Each @fa<record_component_association> shall have at least one associated
+component, and each needed component shall be associated with exactly one
+@fa<record_component_association>. If a @fa<record_component_association> has
+two or more associated components, all of them shall be of the same type.
+@dby
+Each @fa<record_component_association> other than an @b<others> choice with
+a <@> shall have at least one associated
+component, and each needed component shall be associated with exactly one
+@fa<record_component_association>. If a @fa<record_component_association> with
+an expression has two or more associated components, all of them shall be of
+the same type.
+
+!corrigendum 4.3.1(17)
+
+@dinsa
+If the components of a @fa<variant_part> are needed, then the value of a
+discriminant that governs the @fa<variant_part> shall be given by a static
+expression.
+@dinss
+If the type of the @fa<record_aggregate> is a partial view of a type, a
+task type, a protected type, a formal private type, or a formal
+derived type:
+
+@xbullet<The @fa<record_component_association_list> shall include @b<others>
+=@> <@>; and>
+
+@xbullet<The type of the @fa<record_aggregate> shall have known discriminants
+or be a tagged, task, or protected type that does not have unknown
+discriminants; and>
+
+@xbullet<The @fa<record_component_association_list> shall not include a
+positional component association.>
+
+!corrigendum 4.3.2(4)
+
+@drepl
+The expected type for an @fa<extension_aggregate> shall be a single nonlimited
+type that is a record extension. If the @fa<ancestor_part> is an
+@fa<expression>, it is expected to be of any nonlimited tagged type.
+@dby
+The expected type for an @fa<extension_aggregate> shall be a single type that
+is a type extension. If the @fa<ancestor_part> is an @fa<expression>, it is
+expected to be of any tagged type.
+
+
+!corrigendum 4.3.2(5)
+
+@drepl
+If the @fa<ancestor_part> is a @fa<subtype_mark>, it shall denote a specific
+tagged subtype. The type of the @fa<extension_aggregate> shall be derived from
+the type of the @fa<ancestor_part>, through one or more record extensions (and
+no private extensions).
+@dby
+If the @fa<ancestor_part> is a @fa<subtype_mark>, it shall denote a specific
+tagged subtype. The type of the @fa<extension_aggregate> shall be
+a descendant of the type of the @fa<ancestor_part>. If the type of the
+@fa<extension_aggregate> is derived from the type of the @fa<ancestor_part>
+through one or more private extensions, then the
+@fa<record_component_association_list> shall include @b<others> =@> <@>, and
+shall not include a positional component association.
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent