CVS difference for ai12s/ai12-0342-1.txt
--- ai12s/ai12-0342-1.txt 2020/01/11 05:13:40 1.4
+++ ai12s/ai12-0342-1.txt 2020/01/14 05:15:44 1.5
@@ -1,4 +1,4 @@
-!standard 4.2.1(0) 20-01-10 AI12-0342-1/02
+!standard 4.2.1(0) 20-01-11 AI12-0342-1/03
!standard 6.3.1(22)
!reference AI12-0249-1
!reference AI12-0295-1
@@ -44,11 +44,12 @@
In 4.2.1(2/5), delete "nonoverridable, ".
In 4.2.1(3/5, 4/5, and 5/5), replace (once in each)
- "primitive function of T" with "function"
+ "that denotes a primitive function of T" with "that statically denotes a
+ function"
Append after 4.2.1 (5.a/5) (i.e., at the end of the Static Semantics section)
- [AARM note:
+ AARM Ramification:
Thus, the following example is legal because the preceding rules
are name resolution rules (see 13.1.1):
package Pkg1 is
@@ -57,11 +58,11 @@
function Int_Lit (X, Y : T) return Duration; -- wrong profile
function Int_Lit (Lit_Image : String) return T; -- right profile
end;
- end AARM note]
+ End AARM Ramification.
These three aspects are inherited according to the rules given in 13.1.
- [AARM Note:
+ AARM Discussion:
This means that in this example
package Pkg is
type T1 is record
@@ -76,7 +77,7 @@
end Pkg;
the initial value of Pkg.X is (0,0), not (1,1).
- end AARM note]
+ End AARM Discussion.
When a numeric literal is interpreted as value of a non-numeric
type T or a string_literal is interpreted a value of a type T that
@@ -85,40 +86,45 @@
Integer_Literal aspect for an integer literal, the Real_Literal aspect
for a real literal, and the String_Literal aspect for a string_literal.
The actual parameter of this notional call is a string literal
- having the textual representation of the original (numeric or
- string) literal.
+ having the textual representation of the original (numeric or string)
+ literal.
- Such a literal is said to be a "user-defined literal".
-
- [AARM note:
+ AARM Discussion:
This equivalence defines, for example, the nominal type, the nominal
subtype, and the accessibility level of a user-defined literal.
It also has the consequence that a user-defined literal shall not
be of an abstract type (because that would be equivalent to a
nondispatching call to an abstract function). This equivalence
- also defines the dynamic semantics of evaluating a user-defined
- literal.]
+ also defines the dynamic semantics of evaluating a user-defined literal.
+ The (sub)type of the actual parameter to this call is determined by the profile
+ of the appropriate aspect, and the bounds of the string literal are defined
+ by the usual rules for the bounds of a string literal.
+ End AARM Discussion.
+
+ Such a literal is said to be a "user-defined literal".
+
Append after 4.2.1(6/5) (i.e., at the end of the Legality Rules section)
If a nonabstract tagged type inherits any of these three aspects,
then each inherited aspect shall be overridden.
-
+
+Delete 4.2.1(7-8/5).
+ [This is the entire Dynamic Semantics section (it is now redundant).]
+
Replace 6.3.1(22-22.a)
- each primary that is a literal in one has the same value as the
corresponding literal in the other.
- Ramification: The literals may be written differently.
+ AARM Ramification: The literals may be written differently.
with
- each primary that is a literal in one is a user-defined literal
if and only if the corresponding literal in the other is also a
user-defined literal. Furthermore, if neither are user-defined literals
- then they shall have the same values [redundant , but they may have
+ then they shall have the same values Redundant[, but they may have
differing textual representations]; if both are user-defined literals then
they shall have the same textual representation.
-
-delete the entire Dynamic Semantics section (it is now redundant)
!discussion
Questions? Ask the ACAA Technical Agent