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

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

--- ai12s/ai12-0373-1.txt	2020/04/01 00:44:01	1.5
+++ ai12s/ai12-0373-1.txt	2020/04/21 23:35:29	1.6
@@ -1,8 +1,9 @@
-!standard 3.1(1)                                     20-03-31  AI12-0373-1/03
+!standard 3.1(1)                                     20-04-17  AI12-0373-1/04
 !standard 4.2.1(3/5)
 !standard 4.2.1(4/5)
 !standard 4.2.1(5/5)
 !standard 4.9(17.3/5)
+!standard 6.1.1(41/5)
 !standard 13.1.1(4/3)
 !standard 13.1.1(11/3)
 !standard 13.14(3/5)
@@ -27,8 +28,17 @@
 
 (3) Not all entities are (directly) associated with a declaration.
 
-(4) User-defined literal functions can only have a single "in" parameter.
+(4) User-defined literal functions can only have a single nonaliased "in" 
+parameter.
 
+(5) Missing "a" in 6.1.1(41/5).
+
+(6) User-defined literals resolve as expected.
+
+(7) Bit_Order is a representation aspect.
+
+(8) Aggregate is a nonoverridable aspect.
+
 !problem
 
 (1) The definition of statically names excludes any discriminant-dependent
@@ -51,7 +61,22 @@
 function is of type String. But it doesn't specify a mode. Since the parameter
 is passed a string literal, a call to a function with a mode other than "in" 
 would be illegal. Thus, defining the function with an "in out" parameter would
-be useless.
+be useless. Similarly, if the parameter was explicitly aliased, any call would
+be illegal as the actual is not aliased. So that would also be useless as well.
+
+(5) 6.1.1(41/5) says "An implementation may evaluate known-on-entry 
+subexpression of a postcondition expression...". Some word is missing here.
+
+(6) 4.2(8/2) says that an Integer_Literal has type universal_integer. This
+doesn't seem to allow any way for a user-defined literal usage to resolve.
+
+(7) The text defining attribute/aspect Bit_Order does not define the kind of 
+aspect that it is. The usage of the aspect suggests that it is a representation
+aspect, and AARM 13.1(8.l) includes it in a list of representation aspects,
+but there needs to be something normative to this effect.
+
+(8) 4.3.5(12/5) says that Aggregate is a nonoverridable aspect, but the list in
+13.1.1(18.7/5) does not include Aggregate. One of these must be wrong.
 
 !proposal
 
@@ -59,7 +84,7 @@
 
 !wording
 
-Modify 3.1(1):
+Modify 3.1(1): [Item (3)]
 
    The language defines several kinds of named entities that are 
    declared by declarations. The entity's name is defined by the 
@@ -75,41 +100,75 @@
    We don't mention those here as this paragraph is about *named* 
    entities.
 
-Modify 4.2.1(3/5):
+Modify 4.2(4.5): [Item (6)]
+
+   The expected type for a primary that is a string_literal shall be a single
+   string type or a type with a specified String_Literal aspect (see 4.2.1).
+   {In either case, the string_literal is interpreted to be of its expected 
+   type. If the expected type of an integer literal is a type with a specified
+   Integer_Literal aspect (see 4.2.1), the literal is interpreted to be of its
+   expected type; otherwise it is interpreted to be of type universal_integer.
+   If the expected type of a real literal is a type with a specified 
+   Real_Literal aspect (see 4.2.1), it is interpreted to be of its expected 
+   type; otherwise, it is interpreted to be of type universal_real.}
+
+Modify 4.2(8/2): [Item (6)]
+
+   [An integer literal is of type universal_integer. A real literal is of type 
+   universal_real. ]The literal null is of type universal_access.
+
+Modify 4.2.1(3/5): [Item (4)]
    This aspect is specified by a function_name that statically denotes a 
-   function with one {in} parameter of type String and a result type of T.
+   function with {a result type of T and} one {in} parameter {that is} of
+   type String {and is not explicitly aliased}[ and a result type of T].
 
-Modify 4.2.1(4/5):
+Modify 4.2.1(4/5): [Item (4)]
    This aspect is specified by a function_name that statically denotes a 
-   function with one {in} parameter of type String and a result type of T.
+   function with {a result type of T and} one {in} parameter {that is} of
+   type String {and is not explicitly aliased}[ and a result type of T].
 
-Modify 4.2.1(5/5):
+Modify 4.2.1(5/5): [Item (4)]
    This aspect is specified by a function_name that statically denotes a 
-   function with one {in} parameter of type Wide_Wide_String and a result 
-   type of T.
+   function with {a result type of T and} one {in} parameter {that is} of
+   type Wide_Wide_String {and is not explicitly aliased}[ and a result type 
+   of T].
 
-Modify 4.9(17.3/5):
+Modify 4.9(17.3/5): [Item (1)]
 
   * is a selected_component whose prefix statically names an object, there is 
     no implicit dereference of the prefix, and the selector_name [names a 
     component that does not depend on a discriminant] {does not denote a 
     component_declaration occurring within a variant_part}; or 
 
-Modify 13.1.1(4/3):
+Modify 6.1.1(41/5): [Item (5)]
 
+  An implementation may evaluate {a} known-on-entry subexpression of a 
+  postcondition expression of an entity at the place where X'Old constants
+  are created for the entity, with the normal evaluation of the postcondition
+  expression, or both.
+
+Modify 13.1.1(4/3): [Item (2)]
+
   aspect_definition ::= name | expression | identifier{
                       | global_aspect_definition}
 
 
-Modify 13.1.1(11/3):
+Modify 13.1.1(11/3): [Item (2)]
 
   The usage names in an aspect_definition [Redundant: are not resolved
   at the point of the associated declaration, but rather] are resolved
   at the end of the immediately enclosing declaration list{, or in the
   case of the declaration of a library unit, at the end of the visible
   part of the entity}.
+
+Modify 13.1.1(18.7/5) to include aspect Aggregate. [Item (8)]
+  
+Modify 13.5.3(3): [Item (7)]
+
+  For every specific record subtype S, the following {representation }
+  attribute is defined: 
 
-Modify 13.14(3/5):
+Modify 13.14(3/5):  [Item (2)]
 
   The end of a declarative_part, protected_body, or a declaration of a
   library package or generic library package, causes freezing of each
@@ -164,9 +223,25 @@
 (4) The equivalence of 4.2.1(7/5) ensures that no illegal call will be made.
 However, there is no reason to allow the definition of useless things, that
 almost certainly would be a bug, not something intended. So we enhance the
-requirements to require an "in" parameter.
+requirements to require an "in" parameter and to prohibit explicitly aliased
+parameters.
 
+(5) This is a simple typo. Inserting "a" fixes the wording.
 
+(6) The Static Semantics equivalence of 4.2.1(7/5) defines all of the details 
+of what happens to a legal expression that contains a user-defined literal.
+But it seems too much to have that modify resolution as well. Therefore, we
+modify the rules of 4.2 to make it clear how integer and real literals 
+resolve.
+
+(7) The usage of Bit_Order is clear that of a representation aspect, and the
+list of representation aspects in the AARM confirms it. Thus we add wording
+to clarify that Bit_Order is a representation aspect.
+
+(8) It's pretty clear that 4.3.5(12/5) intentionally declares Aggregate as a
+nonoverridable aspect; the omission from the list of 13.1.1(18.7/5) is likely
+an oversight. Thus we correct this.
+
 !corrigendum 3.1(1)
 
 @drepl
@@ -184,6 +259,31 @@
 @fa<indexed_component>, @fa<selected_component>, or dereference @fa<name>s
 (see 4.1).
 
+!corrigendum 4.2(4)
+
+@drepl
+The expected type for a @fa<primary> that is a @fa<string_literal> shall be 
+a single string type. 
+@dby
+The expected type for a @fa<primary> that is a @fa<string_literal> shall be 
+a single string type or a type with a specified String_Literal aspect (see 
+4.2.1). In either case, the @fa<string_literal> is interpreted to be of its 
+expected type. If the expected type of an integer literal is a type with a 
+specified Integer_Literal aspect (see 4.2.1), the literal is interpreted to 
+be of its expected type; otherwise it is interpreted to be of type 
+@i<universal_integer>. If the expected type of a real literal is a type with 
+a specified Real_Literal aspect (see 4.2.1), it is interpreted to be of its 
+expected type; otherwise, it is interpreted to be of type @i<universal_real>.
+
+!corrigendum 4.2(8/2)
+
+@drepl
+An integer literal is of type @i<universal_integer>. A real literal is of type
+@i<universal_real>. The literal @b<null> is of type @i<universal_access>.
+@dby
+The literal @b<null> is of type @i<universal_access>.
+
+
 !corrigendum 4.2.1(0)
 
 @dinsc
@@ -208,6 +308,21 @@
   values that are within the range of the index constraint.>
 For an entity other than an object, a @fa<name> statically names an entity if 
 the @fa<name> statically denotes the entity.
+
+!corrigendum 6.1.1(39/3)
+
+@drepl
+For a call via an access-to-subprogram value, all precondition and
+postcondition checks performed are determined by the subprogram or entry
+denoted by the prefix of the Access attribute reference that produced the
+value.
+@dby
+@s8<@i<Implementation Permissions>>
+
+An implementation may evaluate a known-on-entry subexpression of a
+postcondition expression of an entity at the place where X'Old
+constants are created for the entity, with the normal evaluation of
+the postcondition expression, or both.
 
 !corrigendum 13.1.1(4/3)
 

Questions? Ask the ACAA Technical Agent