CVS difference for ai05s/ai05-0142-4.txt

Differences between 1.12 and version 1.13
Log of other versions for file ai05s/ai05-0142-4.txt

--- ai05s/ai05-0142-4.txt	2010/10/19 03:51:17	1.12
+++ ai05s/ai05-0142-4.txt	2010/10/20 23:03:49	1.13
@@ -1,4 +1,4 @@
-!standard 3.10(9/2)                                  10-08-20  AI05-0142-4/08
+!standard 3.10(9/2)                                  10-10-19  AI05-0142-4/09
 !standard 3.10.2(13.1/2)
 !standard 3.10.2(19/2)
 !standard 6.1(15/2)
@@ -21,7 +21,7 @@
 
 !summary
 
-(See proposal.)
+Parameters can be explicitly marked as aliased.
 
 !problem
 
@@ -31,7 +31,7 @@
 element (potentially in both directions). That could be very expensive if the
 element is large.
 
-The Ada.Containers packages also provide an procedure Update_Element for this
+The Ada.Containers packages also provide a procedure Update_Element for this
 purpose; this provides a writable object as a parameter to a subprogram passed
 into the procedure. This procedure avoids the need to copy the element, but it
 is hardly convenient. The extra syntax needed obscures the real meaning of the
@@ -63,7 +63,7 @@
 
 A view of an object is defined to be *aliased* if it is defined by an object_declaration{,
 parameter_specification, } or component_definition with the reserved word *aliased*, or
-by renaming an aliased view.
+by a renaming of an aliased view.
 
 Add after 3.10.2(13.1/2):
 
@@ -84,11 +84,11 @@
    * Inside a return statement that applies to a function F, when
      determining whether the accessibility level of an explicitly
      aliased parameter of F is statically deeper than the level of the
-     return object of F, the level of the return object is presumed to
+     return object of F, the level of the return object is considered to
      be the same as that of the level of the explicitly aliased
      parameter; for statically comparing with the level of other
      entities, the level of the return object of F is
-     presumed to be the same as that of the master that elaborated
+     considered to be the same as that of the master that elaborated
      the function body of F.
 
 Replace 6.1(15/2) by:
@@ -97,7 +97,7 @@
    defining_identifier_list : [aliased] mode [null_exclusion] subtype_mark [:= default_expression]
  | defining_identifier_list : access_definition [:= default_expression]
 
-Add after 6.1(23): [Static Semantics]
+Add after 6.1(23/2): [Static Semantics]
 
 An *explicitly aliased parameter* is a formal parameter whose parameter_specification includes
 the reserved word *aliased*.
@@ -113,13 +113,23 @@
 A parameter of a by-reference type is passed by reference{, as is an explicitly aliased parameter
 of any type}. Each value...
 
-Modify 6.3.1(16/2):
+Replace 6.3.1(16/2):
 
-Two profiles are mode conformant if they are type-conformant, [and] corresponding parameters
-have identical modes, {both or neither are explicitly aliased parameters}, and, for access
-parameters or access result types, the designated subtypes statically match, or the designated
-profiles are subtype conformant.
+Two profiles are mode conformant if they are type-conformant, and corresponding parameters
+have identical modes, and, for access parameters or access result types, the designated subtypes
+statically match, or the designated profiles are subtype conformant.
+
+by:
+
+Two profiles are mode conformant if:
+ * they are type-conformant;
+ * corresponding parameters have identical modes and both or neither are explicitly
+    aliased parameters; and
+ * for corresponding access parameters and any access result type, the
+    designated subtypes statically match, or the
+    designated profiles are subtype conformant.
 
+
 Add in 6.4.1 of the AARM:
 
 Language Design Principles
@@ -213,12 +223,12 @@
 End AARM reason
 
 AARM Ramification:
-Note that the master given to anonymous objects in explicitly aliased parameters of functions
-is not necessarily as long as the master of the object being initialized (if the funciton
-call is used to initialize an allocator, for instance). In that case, the accessibility
-check on explicitly aliased parameters will necessarily fail if any such anonymous objects
-exist. This is necessary to avoid requiring the objects to live as long as the access type or
-having the implementation complexity of an implicit coextension.
+Note that the lifetime of master given to anonymous objects in explicitly aliased parameters
+of functions is not necessarily as long as the lifetime of the master of the object being
+initialized (if the funciton call is used to initialize an allocator, for instance). In that
+case, the accessibility check on explicitly aliased parameters will necessarily fail if any
+such anonymous objects exist. This is necessary to avoid requiring the objects to live as
+long as the access type or having the implementation complexity of an implicit coextension.
 
 Modify the first sentence of C.6(12):
 
@@ -261,9 +271,9 @@
 Finally, changing the master of all anonymous objects in parameters of functions would make
 function parameters live a long time in some cases (such as when the result is renamed or
 part of an allocator). That could be especially nasty if the parameter is an object that
-contains tasks that otherwise would have been terminated or releases locks when finalized.
-This would be the worst sort of incompatibility, where the program still works but does
-something different.
+contains tasks that otherwise would have been terminated or that releases locks when
+finalized. This would be the worst sort of incompatibility, where the program still works
+but does something different.
 
 ---
 
@@ -277,7 +287,7 @@
 For example:
 
 package Test is
-    type Rec (A : access Integer) is null record; -- Build-in-place type.
+    type Rec (A : access Integer) is null record; -- Type that requires build-in-place.
 
     type A_Rec is access Rec;
 
@@ -285,7 +295,7 @@
 
     function Constructor (Param : aliased in out Integer) return Rec is
     begin
-       return (A => Param'Access);
+       return (A => Param'Access); -- Result built-in-place.
     end Constructor;
 
     procedure Do_It is
@@ -301,16 +311,16 @@
     end if;
 end Test;
 
-Since Rec is built-in-place, its access discriminants have the master of the
-access type A_Rec. That lives longer than the parameter My_Value, which
-is used as the access discriminant. Thus we have to make something illegal
-somewhere. We chose to make an accessibility check at the call site, as this
-do not usually require the overhead of dynamic checks.
+Since the result of Constructor is built-in-place in the allocator, its access
+discriminants have the master of the access type A_Rec. That lives longer than
+the parameter My_Value, which is used as the access discriminant. Thus we have
+to make something illegal somewhere. We chose to make an accessibility check at
+the call site, as this does not usually require the overhead of dynamic checks.
 
 ---
 
 We briefly considered and rejected allowing explicitly aliased function results.
-Such returns would need to work as-if they are returned by reference.
+Such returns would need to work as if they are returned by reference.
 
 We could allow aliased results when a function call is used directly as the actual
 for an explicitly aliased parameter. We already do allow that a function that returns
@@ -331,12 +341,12 @@
 
 For instance:
 
-     type vector is array (positive range <>) of Natural;
+     type Vector is array (Positive range <>) of Natural;
 
-     Actual : aliased vector (1 .. 4); -- Nominal subtype is constrained
+     Actual : aliased Vector (1 .. 4); -- Nominal subtype is constrained
 
-     function Has_Four_Elements (x : aliased in vector) return Boolean is
-         type Ref is access constant vector;
+     function Has_Four_Elements (X : aliased in Vector) return Boolean is
+         type Ref is access constant Vector;
          Ptr : Ref;
      begin
          if X'First > 1 then
@@ -351,9 +361,9 @@
      Has_Four : constant Boolean := Has_Four_Elements (Actual);
 
 (1) is illegal because the subtypes don't statically match. However, (2) is legal because
-the nominal subtype of X does statically match the designated type of Ref, Vector. We don't
-want incentives to pass something as a parameter so it can be used where it would not be
-able to be used directly.
+the nominal subtype of X does statically match the designated type of Ref, namely Vector.
+We don't want incentives to pass something as a parameter so it can be used where it would
+not be able to be used directly.
 
 Note that this check in the array case is primarily about implementations being able to
 continue to require a contiguous representation of array dope. If the compiler does
@@ -509,11 +519,11 @@
 @xbullet<Inside a return statement that applies to a function @i<F>, when
 determining whether the accessibility level of an explicitly
 aliased parameter of @i<F> is statically deeper than the level of the
-return object of @i<F>, the level of the return object is presumed to
+return object of @i<F>, the level of the return object is considered to
 be the same as that of the level of the explicitly aliased
 parameter; for statically comparing with the level of other
 entities, the level of the return object of @i<F> is
-presumed to be the same as that of the master that elaborated
+considered to be the same as that of the master that elaborated
 the function body of @i<F>.>
 
 
@@ -532,11 +542,11 @@
 !corrigendum 6.1(23/2)
 
 @dinsa
-The nominal subtype of a formal parameter is the subtype denoted
-by the @fa<subtype_mark>, or
+The nominal subtype of a formal parameter is the subtype determined by the optional
+@fa<null_exclusion> and the @fa<subtype_mark>, or
 defined by the @fa<access_definition>, in the @fa<parameter_specification>.
 The nominal subtype of a function result is the subtype
-denoted by the @fa<subtype_mark>, or
+determined by the optional @fa<null_exclusion> and the @fa<subtype_mark>, or
 defined by the @fa<access_definition>, in the @fa<parameter_and_result_profile>.
 @dinst
 An @i<explicitly aliased parameter> is a formal parameter whose @fa<parameter_specification>
@@ -575,11 +585,12 @@
 access result types, the designated subtypes statically match, or the
 designated profiles are subtype conformant.
 @dby
-Two profiles are @i<mode conformant> if they are type conformant,
-corresponding parameters have identical modes, both or neither are explicitly
-aliased parameters, and, for access parameters or access result types, the
-designated subtypes statically match, or the designated profiles are subtype
-conformant.
+Two profiles are @i<mode conformant> if:
+@xbullet<they are type-conformant;>
+@xbullet<corresponding parameters have identical modes and both or neither are explicitly
+aliased parameters; and>
+@xbullet<for corresponding access parameters and any access result type, the
+designated subtypes statically match, or the designated profiles are subtype conformant.>
 
 
 !corrigendum 6.4.1(6)

Questions? Ask the ACAA Technical Agent