CVS difference for ai12s/ai12-0059-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0059-1.txt

--- ai12s/ai12-0059-1.txt	2015/10/06 02:39:10	1.5
+++ ai12s/ai12-0059-1.txt	2015/11/20 03:11:26	1.6
@@ -1,4 +1,4 @@
-!standard 13.03 (58)                              15-10-05    AI12-0059-1/05
+!standard 13.03 (58)                              15-10-17    AI12-0059-1/06
 !class Amendment 13-01-30
 !status work item 13-01-30
 !status received 12-09-21
@@ -61,6 +61,70 @@
 
 !wording
 
+Modify the first sentence of 4.9.1(2/3) to:
+
+A subtype statically matches another subtype of the same type if they
+have statically matching constraints, all predicate specifications that
+apply to them come from the same declarations, {Object_Size (see 13.3)
+has been specified to have a nonconfirming value either for both or
+neither, and the nonconfirming values, if any, are the same,} and, for
+access subtypes, either both or neither exclude null.
+
+    AARM Ramification: If one of the subtypes is not yet frozen, an
+    implementation may have to repeat the check when the subtypes are both
+    frozen. This can only make a previously statically matching subtype fail
+    to match; it cannot make a match legal.
+
+    AARM Discussion: We include the case where both Object_Sizes are
+    confirming so that we don't introduce an incompatibility for
+    existing Ada code. But practically the implementation can simply
+    check that the Object_Size values are the same, as we have a rule in
+    13.1(14) that the subtype-specific aspects (such as Object_Size) are
+    always the same for statically matching subtypes. We wrote the rules
+    this way to avoid having wording that appeared to require predicting
+    the future ("would statically match if ...").
+
+Modify 13.1(14 and 14.a/3):
+  If two subtypes statically match, then their subtype-specific aspects
+  ({for  example, }Size and Alignment) are the same.
+
+   AARM Reason: This is necessary because we allow (for example)
+   conversion between access types whose designated subtypes statically
+   match. Note that most aspects (including the subtype-specific aspects
+   Size and Alignment) may not be specified for a nonfirst subtype. The
+   only language-defined exceptions to this rule are the {Object_Size,}
+   Static_Predicate{,} and Dynamic_Predicate aspects.
+
+Add the following after 13.1(14.a/3):
+
+   AARM Reason: The above existing static matching rule combined
+   with the updated definition of static matching in 4.9.1(2)
+   does not cause incompatibilities in existing Ada code that does not
+   mention Object_Size. Note that 13.1(14) applies even to the
+   implementation-defined value of Object_Size when it is not specified.
+
+   AARM Discussion: We need this rule even though static matching explicitly
+   excludes confirming values of Object_Size. That's because a general access
+   type can designate any aliased object whose subtype statically matches the
+   the designated subtype. Since the Object_Size of a subtype determines the
+   number of bits allocated for an aliased object of the subtype, if we
+   allowed different Object_Sizes for statically matching subtypes, we'd be
+   allowing the access type to designate objects with differing numbers of
+   bits. That isn't going to work.
+
+Add Object_Size to 13.1(23):
+
+An implementation need not support a specification for the Size {or
+Object_Size} for a given composite subtype, nor the size or storage place for
+an object (including a component) of a given composite subtype, unless the
+constraints on the subtype and its composite subcomponents (if any) are all
+static constraints.
+
+   {AARM Reason: We don't want to require that Size or Object_Size be
+    supported on types that might have a representation not completely
+    specified at compile-time, or are represented discontiguously, or are
+    represented differently for different constraints.}
+
 [Editor's note: The below wording is in the style of 13.3, which is where it
 will be placed in the Standard. As such, it does not mention aspect
 specifications, it only talks about the attribute. This is intended.]
@@ -73,17 +137,20 @@
 
 For every subtype S:
 
-S'Object_Size	If S is definite, denotes the size (in bits) of a component
-or stand-alone aliased object of subtype S, in the absence of a
-aspect_specification or representation item that specifies the size of 
-the component or object. If S is indefinite, the meaning is
-implementation-defined. The value of this attribute is of the
-type universal_integer. If not specified otherwise, the Object_Size of a
-subtype is at least as large as the Size of the subtype. Object_Size may be
-specified via an attribute_definition_clause; the expression of such a clause
-shall be static and its value nonnegative. All aliased objects with nominal
-subtype S have the size S'Object_Size. If S1 and S2 are two subtypes that
-statically match, then S1'Object_Size equals S2'Object_Size.
+S'Object_Size	If S is definite, denotes the size (in bits) of a
+stand-alone aliased object, or a component of subtype S in the absence
+of an aspect_specification or representation item that specifies the
+size of the object or component. If S is indefinite, the meaning is
+implementation-defined. The value of this attribute is of the type
+universal_integer. If not specified otherwise, the Object_Size of a
+subtype is at least as large as the Size of the subtype. Object_Size may
+be specified via an attribute_definition_clause; the expression of such
+a clause shall be static and its value nonnegative. All aliased objects
+with nominal subtype S have the size S'Object_Size. In the absence of
+an explicit specification, the Object_Size of a subtype S defined by a
+subtype_indication without a constraint, is that of the value of the
+Object_Size of the subtype denoted by the subtype_mark of the
+subtype_indication, at the point of this definition.
 
    AARM Ramification:
    We allow the specification of Object_Size for any subtype (*not* just first
@@ -91,22 +158,6 @@
    restrictions on which subtypes allow specification of Object_Size (as
    with any representation attribute).
 
-   AARM Reason: The static matching rule is necessary so that the addition of
-   Object_Size does not cause incompatibilities in existing Ada code that does
-   not use Object_Size. Note that this rule applies even to the
-   implementation-defined value of Object_Size when it is not specified. That's
-   needed because Object_Size is never inherited for a subtype, it is
-   independently determined for every subtype.
-
-   AARM Discussion: We need this rule even though static matching explicitly
-   excludes confirming values of Object_Size. That's because a general access
-   type can designate any aliased object whose subtype statically matches the
-   the designated subtype. Since the Object_Size of a subtype determines the
-   number of bits allocated for an aliased object of the subtype, if we
-   allowed different Object_Sizes for statically matching subtypes, we'd be
-   allowing the access type to designate objects with differing numbers of
-   bits. That isn't going to work.
-
 [Editor's note: The Pittsburgh meeting asked that this be changed to "aliased
 variable", because "one can imagine constants taking advantage of discriminants
 not changing." That's true for nonaliased constants, but an aliased
@@ -185,9 +236,9 @@
    no smaller than S'Size, and that is no larger than that of the largest
    composite subtype supported by the implementation.
 
-  AARM Discussion: Any extra bits required this way will be trailing padding bits.
-  Unlike elementary objects, padding bits can be considered part of composite
-  objects.
+  AARM Discussion: Any extra bits required this way will be trailing
+  padding bits. Unlike elementary objects, padding bits can be
+  considered part of composite objects.
 
  * If S is some other subtype, only confirming specifications of Object_Size
    need be supported.
@@ -221,41 +272,7 @@
 13.3(50-2) for non-first subtypes. Thus it's pointless to obsess about getting
 it perfect for every possible implementation.]
 
-Modify the first sentence of 4.9.1(2/3) to:
-
-A subtype statically matches another subtype of the same type if they have
-statically matching constraints, all predicate specifications that apply to
-them come from the same declarations, {their Object_Sizes (see 13.3) are the
-same if either is nonconfirming,} and, for access subtypes, either both or
-neither exclude null. 
-
-    AARM Ramification: If one of the subtypes is not yet frozen, an
-    implementation may have to repeat the check when the subtypes are both
-    frozen. This can only make a previously statically matching subtype fail
-    to match; it cannot make a match legal.
-
-    AARM Discussion: We exclude the case where both Object_Sizes are
-    confirming so that we don't introduce an incompatibility for existing
-    Ada code. But practically the implementation can simply check that
-    the Object_Size values are the same, as we have an Implementation
-    Requirement that the Object_Size values are always the same for
-    statically matching subtypes. We wrote the rules this way to avoid
-    having wording that appeared to require predicting the future ("would
-    statically match if ...").
 
-Add Object_Size to 13.1(23):
-
-An implementation need not support a specification for the Size {or
-Object_Size} for a given composite subtype, nor the size or storage place for
-an object (including a component) of a given composite subtype, unless the
-constraints on the subtype and its composite subcomponents (if any) are all
-static constraints.
-
-    AARM Reason: We don't want to require that Size or Object_Size be
-    supported on types that might have a representation not completely
-    specified at compile-time, or are represented discontiguously, or are
-    represented differently for different constraints.
-
 !discussion
 
 Object_Size covers the cases that are not specified by Size. Size is only
@@ -1088,6 +1105,17 @@
 > in a packed record.
 
 Right, although as Randy pointed out, that's not a particularly useful feature.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 17, 2015  12:59 PM
+
+Here is an update to the Object_Size aspect [This is version /06 of the AI -
+Editor].  I re-ordered paragraphs so they are in numerical order.  I struggled
+over 4.9.1 -- I think the current wording is the best of a set of nasty
+alternatives.  We now rely on the existing rule in 13.1(14) about static
+matching implies subtype-specific aspect matching.  Enjoy!
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent