CVS difference for ai05s/ai05-0228-1.txt

--- ai05s/ai05-0228-1.txt	2010/10/22 05:38:37	1.1
+++ ai05s/ai05-0228-1.txt	2010/11/18 06:01:11	1.2
@@ -1,15 +1,20 @@
-!standard 3.3.1(10)                                    10-10-22  AI05-0228-1/01
+!standard 3.3.1(11)                                    10-11-17  AI05-0228-1/02
+!standard 3.3.1(12)
 !standard 3.3.1(21)
+!standard 3.5(56/2)
+!standard 3.6(22/2)
+!standard 6.4(13)
 !class Amendment 10-10-22
 !status work item 10-10-22
 !status received 10-10-22
 !priority Medium
 !difficulty Easy
-!subject Default initial values for types
+!subject Default initial values for scalar and array types
 
 !summary
 
-(See proposal.)
+Two new aspects are added to provide default initial values for scalar types
+and arrays of scalar types.
 
 !problem
 
@@ -26,18 +31,35 @@
 
 !proposal
 
-Add an aspect Default_Value, that can be used on all types.
+Add an aspect Default_Value that can be used on all scalar types, and an
+additional aspect Default_Component_Value that can be used on all array of scalar
+types.
 
 !wording
 
-Modify 3.3.1(10):
+Add a new bullet after 3.3.1(11):
 
-   For an object_declaration without an initialization expression, any initial
-   values for the object or its subcomponents are determined by the implicit
-   initial values defined for its nominal subtype{. If the subtype has the
-   Default_Value aspect specified, the implicit initial value is the value of
-   that aspect. Otherwise, the value is determined}[,] as follows:
+* The implicit initial value for a scalar subtype that has the Default_Value
+  aspect specified is the value of that aspect converted to the nominal subtype
+  (which might raise Constraint_Error - see 4.6, “Type Conversions”);
+
+
+Modify 3.3.1(13):
+
+* For a (definite) composite subtype, the implicit initial value of each component
+  with a default_expression is obtained by evaluation of this expression and
+  conversion to the component's nominal subtype (which might raise Constraint_Error
+  [— see 4.6, “Type Conversions”]), unless the component is a discriminant of
+  a constrained subtype (the previous case), or is in an excluded variant (see 3.8.1).
+  For each component that does not have a default_expression, {if the composite
+  subtype has the Default_Component_Value aspect specified, the implicit initial value
+  is the value of that aspect is converted to the component's nominal subtype;
+  otherwise, } any implicit initial values are those determined by the component's
+  nominal subtype.
 
+[Editor's note: We delete the cross-reference because it has been moved into the new
+bullet; we don't repeat cross-references in paragraphs that will be read together.]
+
 Modify 3.3.1(21):
 
 There is no implicit initial value for a scalar subtype{ unless the
@@ -46,28 +68,94 @@
 aspect}, a newly created scalar object might have a value that does not belong
 to its subtype (see 13.9.1 and H.1).
 
-Add after 3.3.1(21): [Better place for this?]
+Add after 3.5(56/2):
 
-  Static Semantics
+Static Semantics
 
-  For a full type, the following language-defined aspect
+  For a scalar type, the following language-defined aspect
   may be specified with an aspect_specification:
     Default_Value
-       This aspect shall be specified by an expression, called an *default
-       value expression*.
-       Type_Invariant may be specified on a full_type_declaration.
+       This aspect shall be specified by a static expression.
+       Default_Value shall be specified only on a full_type_declaration.
 
   Name Resolution
+
+The expected type for the expression specified for the Default_Value aspect is
+the type defined by the full_type_declaration.
+
+Add after 3.6(22/2):
 
-The expected type for a default value expression is the type defined by
-the full_type_declaration.
+Static Semantics
 
-  Dynamic Semantics
+  For an array type with a scalar component type, the following
+  language-defined aspect may be specified with an aspect_specification:
+    Default_Component_Value
+       This aspect shall be specified by a static expression.
+       Default_Component_Value shall be specified only on a full_type_declaration.
 
-The default value expression is evaluated at the first freezing point of the
-type, and the result becomes the value of the aspect for the type.
+  Name Resolution
+
+The expected type for the expression specified for the Default_Component_Value aspect
+is the component type of the array type defined by the full_type_declaration.
 
+Add a new bullet after 6.4(13): [Note that 6.4(13) was modified by AI05-0196-1 --
+we echo that wording here, not the original wording.]
 
+* For a scalar type that has the Default_Value aspect specified, the formal parameter
+  is initialized from the value of the actual, without checking that the value satisfies
+  any constraint; 
+
+AARM Reason: This preserves the language design principle that all objects of a type
+with an implicit initial value are initialized. This is important so that a programmer
+can guarantee that all objects of a scalar type have a valid value with a carefully
+chosen Default_Value.
+
+[Editor's note: We don't need to modify the composite rule, as the changed definition
+of "implicit initial values" effectively changes this rule to include arrays with
+a specified Default_Component_Value.]
+
+Modify AARM 6.4(15.a):
+
+This case covers scalar types {that do not have Default_Value specified}, and composite
+types whose subcomponent's subtypes do not have any implicit initial values. The
+view conversion for composite types ensures that if the lengths don't match between
+an actual and a formal array parameter, the Constraint_Error is raised before the call,
+rather than after. 
+
+
+Modify 13.13.2(35/2):
+
+In the default implementation of Read and Input for a composite type, for each scalar
+component that is a discriminant or [whose component_declaration includes a
+default_expression]{that has an implicit initial value}, a check is made that the value
+returned by Read for the component belongs to its subtype. Constraint_Error is raised if
+this check fails. For other scalar components, no check is made. For each component that
+is of an access type, if the implementation can detect that the value returned by Read
+for the component is not a value of its subtype, Constraint_Error is raised. If the
+value is not a value of its subtype and this error is not detected, the component has
+an abnormal value, and erroneous execution can result (see 13.9.1). In the default
+implementation of Read for a composite type with defaulted discriminants, if the actual
+parameter of Read is constrained, a check is made that the discriminants read from the
+stream are equal to those of the actual parameter. Constraint_Error is raised if this
+check fails.
+
+AARM To Be Honest: An implementation should always be able to detect the
+error for an access subtype with a null exclusion; the "if the implementation can detect"
+is intended to cover non-null access values.
+
+AARM Ramification: A scalar component can have an implicit initial value if it has a
+default_expression, if the component's type has the Default_Value aspect specified,
+or if the component is that of an array type that have the Default_Component_Value
+aspect specified.
+
+[Question: There does not seem to be any corresponding rule for elementary 'Read.
+That means that it is possible to stream in values not in italized T. That seems bad for
+types that have implicit initial values. For access and integer types, there cannot be
+values that are not in italized T (no null exclusion is applied, and T'Base covers all
+possible bit patterns for integers). But that is definitely not the case for enumeration
+and floating point types. Should there be some sort of check here in those cases? This
+seems to be the only non-erroneous way of creating an invalid value for such types, other
+than by using unchecked programming. -- Randy.]
 
 !discussion
 
@@ -78,6 +166,8 @@
 However, if a type has a value specifically that means "Unknown" or "Undefined",
 it makes perfect sense to initialize all objects to that value. That would
 greatly reduce the chances of invalid objects of the type existing.
+
+Note that the change to the definition of "implicit initial values"
 
 !examples