CVS difference for ais/ai-00389.txt

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

--- ais/ai-00389.txt	2004/12/09 19:55:38	1.3
+++ ais/ai-00389.txt	2005/04/13 05:37:19	1.4
@@ -4,7 +4,8 @@
 !standard 4.3.2(4)
 !standard 4.3.2(5)
 !class amendment 04-11-11
-!status Amendment 200Y 04-12-03
+!status No Action (10-0-0) 05-02-12
+!status work item 05-02-07
 !status ARG Approved 5-0-5  04-11-20
 !status work item 04-11-11
 !status received 04-11-11
@@ -475,6 +476,103 @@
 Yuck. I suppose we could try to give a name to that, but its a mixture of
 views and types. Or maybe put that into a header and make the legality rules
 bullets.
+
+****************************************************************
+
+From: Editor
+
+This AI was voted No-Action in Paris, after the complexities got out of
+hand. There were a number of useful AARM notes explaining the rules in this
+AI. I've copied them here to save them for posterity (especially if this
+idea is resurrected in the future).
+
+Add after 4.3.1(17):
+
+17.2/2{AI95-00389-01} 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:
+
+17.3/2{AI95-00389-01} The record_component_association_list shall include
+others => <>; and
+
+17.c/2Reason: 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.
+
+17.d/2For tasks and protected types, this recognizes that there may be
+      components (such as the lock for a protected type) that are known only 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.
+
+17.4/2{AI95-00389-01} 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
+
+17.e/2Reason: 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). The full type is certain to
+      be composite if the partial view has known discriminants or is tagged.
+      Task and protected types are also allowed, as they are always composite.
+
+17.f/2We 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. Moreover, we would have break privacy to make them work. For
+      instance:
+
+17.g/2package P is
+         type T (<>) is tagged private;
+      private
+         type T (D : Natural) is tagged record
+            C : String (1..D);
+         end record;
+      end P;
+
+17.h/2We couldn't allow giving an aggregate for T outside of P, because we
+      don't know what value to give the discriminant D. But that would require
+      looking in the private part to see if D had a default. It's better to
+      disallow unknown discriminants generally.
+
+17.5/2{AI95-00389-01} The record_component_association_list shall not include a
+positional component association.
+
+17.i/2Reason: 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 and complexity; 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 4.3.2(5) by:
+
+5/2     {AI95-00306-01} {AI95-00389-01} 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 ancestor_part
+is an expression, it shall not be dynamically tagged. 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.
+
+5.a/2Reason: {AI95-00306-01} The expression cannot be dynamically tagged to
+     prevent implicit "truncation" of a dynamically-tagged value to the
+     specific ancestor type. This is similar to the rules in 3.9.2.
+
+5.b/2{AI95-00389-01} We allow the type of the ancestor_part to be the type
+     itself, so that these aggregates are allowed for generic formal derived
+     types, where the actual type might be the same as the ancestor type.
+
+5.c/2{AI95-00389-01} 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.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent