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

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0249-1.txt

--- ai12s/ai12-0249-1.txt	2018/01/25 07:32:08	1.2
+++ ai12s/ai12-0249-1.txt	2018/11/28 07:25:13	1.3
@@ -1,6 +1,7 @@
-!standard 4.2(5)                                     18-01-22  AI12-0249-1/01
+!standard 4.2(5)                                     18-10-23  AI12-0249-1/02
 !standard 4.2(6)
 !standard 4.2.1(0)
+!standard 4.9(3)
 !class Amendment 18-01-22
 !status work item 18-01-22
 !status received 15-03-20
@@ -9,7 +10,7 @@
 !subject User-defined literals
 !summary
 
-** TBD.
+A mechanism for user-defined literals is added.
 
 !problem
 
@@ -44,34 +45,33 @@
 universal type of the literal "covers" the specified class.
 
 Since no types currently have Literal aspects, there is no immediate
-upward compatibility issue.  However, if we decide to add Literal
+upward compatibility issue. However, if we decide to add Literal
 aspects to any existing language-defined types (such as
 Unbounded_String), we will be potentially creating ambiguities.
 
 We need to decide how to represent the literals, and how to convert
-them.  For character and string literals, we have Wide_Wide_Characters
+them. For character and string literals, we have Wide_Wide_Characters
 and Wide_Wide_Strings, so these represent "universal" representations
-which can accommodate any character set known in the universe.  For
+which can accommodate any character set known in the universe. For
 numeric literals, we could choose a string representation, or some kind
-of Long_Long_Integer or Long_Long_Real.  So long as all conversions of
+of Long_Long_Integer or Long_Long_Real. So long as all conversions of
 literals are propagated to a library-unit elaboration procedure for
 library-level types, and to the point of declaration of the type for
 nested types, the overhead of converting literals can be kept
-manageable.  One might often hope the conversion routines could be
+manageable. One might often hope the conversion routines could be
 evaluated statically, but clearly we are getting into compiler-specific
 optimizations.
 
 Because one use for numeric literals would be for extended precision
 types, it seems wiser to represent a numeric literal as a string, and
 require the type to provide a conversion function from string to the
-type.  As mentioned above, the overhead of conversion can hopefully be
+type. As mentioned above, the overhead of conversion can hopefully be
 reduced by having the compiler "hoist" the literals to a point where the
 conversions are only performed at most once at run-time, and ideally at
-compile or link time.  Because the conversion might fail, we need to
+compile or link time. Because the conversion might fail, we need to
 specify that it is a bounded error if a literal conversion function
 propagates an exception, with consequences being a compile-time or
-link-time error, or a Program_Error propagated prior to the point where
-the value of the literal is used, or the exception propagated by the
+link-time error, or a Program_Error or the exception propagated by the
 conversion function, raised at the point where the value of the literal
 is used.
 
@@ -127,10 +127,10 @@
  {If its expected type is a numeric type, t}[T]he evaluation of a
  numeric literal[, or the literal null,] yields the represented value.
  {If its expected type is an access type, the evaluation of the literal
- null yields the null value of the expected type.}  In other cases,
+ null yields the null value of the expected type. In other cases,
  the effect of evaluating a numeric or null literal is determined by the
  Integer_Literal, Real_Literal, or Null_Literal aspect that applies
- (see 4.2.1).
+ (see 4.2.1).}
 
 Modify paragraph 4.2(10):
  The evaluation of a string_literal that is a primary {and has an
@@ -138,7 +138,7 @@
  type as its component type,} yields an array value containing the value
  of each character of the sequence of characters of the string_literal,
  as defined in 2.6. The bounds of this array value are determined
- according to the rules for positional_array_aggregates (see 4.3.3 ),
+ according to the rules for positional_array_aggregates (see 4.3.3),
  except that for a null string literal, the upper bound is the
  predecessor of the lower bound.
 
@@ -152,7 +152,7 @@
  range of the index type. The exception Constraint_Error is raised if
  either of these checks fails.
 
-Add section 4.2.1 User-Defined Literals
+Add subclause 4.2.1 User-Defined Literals
 
 Using one or more of the aspects defined below, a type may be specified
 to allow the use of one or more kinds of literals as values of the type.
@@ -160,7 +160,7 @@
    Static Semantics
 
 The following nonoverridable, type-related operational aspects may be
-specified for a type T other than a numeric type:
+specified for any type T:
 
   Integer_Literal
     This aspect is specified by a /function_/name that denotes a
@@ -173,7 +173,7 @@
     result type of T.
 
 The following nonoverridable, type-related operational aspect may be
-specified for a type T other than an access type:
+specified for a type T:
 
   Null_Literal
     This aspect is specified by a name that denotes a constant object of
@@ -181,8 +181,7 @@
     and a result type of T.
 
 The following nonoverridable, type-related operational aspect may be
-specified for a type T, unless T is a one-dimensional array type whose
-component type is a character type:
+specified for a type T:
 
   String_Literal
     This aspect is specified by a /function_/name that denotes a
@@ -204,14 +203,26 @@
   considered a
   /character/ type.]
 
+  Legality Rules
 
+The Integer_Literal or Real_Literal aspect shall not be specified for a
+type T if the full view of T is a numeric type. The Null_Literal aspect
+shall not be specified for a type T if the full view of T is an access
+type. The Character_Literal aspect shall not be specified for a type T
+if the full view of T is a character type (in the absence of the
+Character_Literal aspect specification). The String_Literal aspect shall
+not be specified for a type T if the full view of T is a string type (in
+the absence of the String_Literal aspect specification). In addition to
+the places where Legality Rules normally apply (see 12.3), these rules
+also apply in the private part of an instance of a generic unit.
+
   Dynamic Semantics
 
 For the evaluation of an integer (or real) literal with expected type
 having an Integer_Literal (or Real_Literal) aspect specified, the value
 is the result of a call on the function specified by the aspect, with
-the parameter being a string whose value corresponds to the textual
-representation of the integer (or real) literal.
+the parameter being a string with lower bound one whose value corresponds
+to the textual representation of the integer (or real) literal.
 
 For the evaluation of a null literal with expected type having a
 Null_Literal aspect specified, the value is the that of the constant
@@ -226,27 +237,39 @@
 For the evaluation of a string_literal with expected type having a
 String_Literal aspect specified, the value is the result of a call on
 the function specified by the aspect, with the parameter being the
-Wide_Wide_String that corresponds to the literal.
+Wide_Wide_String with lower bound one that corresponds to the literal.
 
   Implementation Permissions
 
 For a literal with an expected type having a corresponding _Literal
-aspect specified, the implementation is permitted to evaluate the
-literal at compile time, or at run time at any point after the freezing
-point of the expected type, and prior to the first use of the value of
-the literal. Furthermore, if two such literals with the same expected
-type have identical textual representations, the result of evaluating
-one of the literals may be used as the value for both literals.
+aspect specified to denote a function that has a Global aspect that
+indicates that there are no references to global variables, the
+implementation is permitted to evaluate the literal at compile time, or
+at run time at any point after the freezing point of the expected type,
+and prior to the first use of the value of the literal. Furthermore, if
+two such literals with the same expected type have identical textual
+representations, the result of evaluating one of the literals may be
+used as the value for both literals.
 
   Bounded Errors
 
 It is a bounded error if the evaluation of a literal with expected type
 having a corresponding _Literal aspect specified, propagates an
-exception.  The possible effect is that an error is reported prior to
-run time, Program_Error is raised at some point prior to any use of
-the value of the literal, or the exception propagated by the evaluation
+exception. The possible effect is that an error is reported prior to
+run time, or Program_Error or the exception propagated by the evaluation
 is raised at the point of use of the value of the literal.
 
+Modify 4.9(3) and the following AARM note:
+
+  * a numeric_literal {of a numeric type};
+
+    AARM Ramification: A numeric_literal {of a numeric type} is always a
+    static expression, even if its expected type is not that of a static
+    subtype. However, if its value is explicitly converted to, or 
+    qualified by, a nonstatic subtype, the resulting expression is
+    nonstatic. {Non-numeric types can have numeric literals if aspect
+    Integer_Literal or Real_Literal is used; these are never static.}
+
 !discussion
 
 The !proposal section includes a relatively complete discussion of the
@@ -258,9 +281,12 @@
   used the type's "-" operator, while a type supporting user-defined
   literals bypassed the "-" operator.
 
-* A literal may be usable on a partial view but not on the full view,
-  if the full view is a type that already has meaning for the same
-  sort of literal.  That seems OK.
+* We do not want to have a situation where a literal may be usable on a
+  partial view but not on the full view, for example, because the full
+  view is a type that already has meaning for the same sort of literal.
+  This avoids problems with full conformance checking when the meaning
+  of a literal might be different in the visible and private parts of a
+  package.
 
 * More generally, we chose to allow user-defined literals on almost
   any sort of type, so long as that sort of type didn't already allow
@@ -276,41 +302,26 @@
   user-defined numeric literals.  Having the presence or absence of
   a "." seemed too subtle to trigger a completely different effect
   when the expected type was a numeric type.
-
-* If we go with this proposal, we will have to decide whether to use
-  this feature for existing language-defined packages
-  (e.g. Unbounded_Strings), and if so, whether certain existing
-  functions should be eliminated from the packages (e.g. overloadings
-  of "&" and the comparison operators that have String as one of
-  the operand types).  At this stage it might be safer to define a
-  new package and move the original Unbounded_Strings package to
-  Annex J.
-
-  Alternatively, we could define some kind of "preference"
-  for or against user-defined interpretation of literals, though we
-  know that "Beaujolais" effects are lurking around the corner when
-  you set up preference rules.  We already have some preference rules
-  dealing with "root" numeric types, and these could be seen as similar,
-  but the root-numeric-type preference avoids Beaujolais effects because
-  the preference is for operations that are always visible.
 
-  So barring some clear proof of being Beaujolais-effect-free, we should
-  probably steer clear of a preference rule.
+* We have decided not to use this feature for existing language-defined
+  packages (such as Unbounded_Strings). We believe it would be safer to
+  define (in some future standard) a new package and move the original
+  Unbounded_Strings package to Annex J.
 
 !examples
 
-   type Unbounded_String is private
-     with String_Literal => To_Unbounded_String;
+   type Varying_String is private
+     with String_Literal => To_Varying_String;
 
-   function To_Unbounded_String (Source : Wide_Wide_String)
-     return Unbounded_String;
+   function To_Varying_String (Source : Wide_Wide_String)
+     return Varying_String;
 
    ...
 
-   X : constant Unbounded_String := "This is a test";
+   X : constant Varying_String := "This is a test";
      --  Equivalent to:
-     --  X : constant Unbounded_String :=
-     --        To_Unbounded_String
+     --  X : constant Varying_String :=
+     --        To_Varying_String
      --           (Wide_Wide_String'("This is a test"));
 
    type Big_Integer is private
@@ -856,7 +867,8 @@
 handled by an equivalence rule, then it should be.
      T'("abc")
 is equivalent to
-     T'(T'String_Literal_Function (Wide_String_Param => "abc")) and we don't need to say any more than that about the bounds of the Wide_Wide_String literal.
+     T'(T'String_Literal_Function (Wide_String_Param => "abc")) and we don't
+need to say any more than that about the bounds of the Wide_Wide_String literal.
 
 Note that the parameter subtype of the String_Literal function can be
 constrained.
@@ -1316,3 +1328,114 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Wednesday, November 28, 2018  1:03 AM
+
+(1) This AI will be split into three AIs as requested. The string and character
+versions will build on the rules given in the base AI for numeric literals.
+
+(2) The summary is "** TBD". That won't get past editorial review (right, 
+John??).
+
+I changed it to "A mechanism for user-defined <blah> literals is added." 
+(where <blah> is appropriate for the AI).
+
+(3) The first line of my meeting notes says that "We need numeric_literals 
+that are non-static, so 4.9(3) needs an update." This wasn't in the AI that
+Tucker sent, so I changed this to:
+
+  * a numeric_literal {of a numeric type};
+
+    AARM Ramification: A numeric_literal {of a numeric type} is always a 
+    static expression, even if its expected type is not that of a static 
+    subtype. However, if its value is explicitly converted to, or qualified
+    by, a nonstatic subtype, the resulting expression is nonstatic.
+    {Non-numeric types can have numeric literals if aspect Integer_Literal 
+    or Real_Literal is used; these are never static.}
+
+I used this wording so as to leave the meaning unchanged in existing cases.
+(Else I would have used "of a static subtype".)
+
+(4) In e-mail, we agreed to limit the Bounded Error to raising exceptions 
+only at the location of a literal. That is not reflected in the Bounded 
+Error wording in the AI. I've corrected the wording for this:
+
+It is a bounded error if the evaluation of a literal with expected type
+having a corresponding _Literal aspect specified, propagates an
+exception. The possible effect is that an error is reported prior to
+run time, or Program_Error or the exception propagated by the evaluation
+is raised at the point of use of the value of the literal.
+
+[We always allow Program_Error to be raised by a Bounded Error.]
+
+(5) I had pointed out the insertion marks in the change for 4.2(9) are screwed
+up; but those were not fixed. I've corrected that paragraph as follows:
+
+Modify paragraph 4.2(9):
+
+ {If its expected type is a numeric type, t}[T]he evaluation of a
+ numeric literal[, or the literal null,] yields the represented value.
+ {If its expected type is an access type, the evaluation of the literal
+ null yields the null value of the expected type. In other cases,
+ the effect of evaluating a numeric or null literal is determined by the
+ Integer_Literal, Real_Literal, or Null_Literal aspect that applies
+ (see 4.2.1).}
+
+(6) The AI has "Add section 4.2.1 ...". But this is a "subclause", not a 
+"section". Fixed accordingly.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, November 28, 2018  1:21 AM
+
+Pushed send too soon.
+
+(7) In e-mail discussion, we had agreed that we needed to define the bounds 
+of the string passed to these routines (for numeric and string literals). 
+There doesn't seem to be any reason to get fancy here, so I just added that
+the lower bound of that string is one (the upper bound then is obvious 
+without needing discussion).
+
+Specifically:
+
+For the evaluation of an integer (or real) literal with expected type having 
+an Integer_Literal (or Real_Literal) aspect specified, the value is the result
+of a call on the function specified by the aspect, with the parameter being a
+string with lower bound one whose value corresponds to the textual 
+representation of the integer (or real) literal.
+
+and
+
+For the evaluation of a string_literal with expected type having a 
+String_Literal aspect specified, the value is the result of a call on the 
+function specified by the aspect, with the parameter being the 
+Wide_Wide_String with lower bound one that corresponds to the literal.
+
+(8) For the string literal case, the wording defines such types as "string 
+types". I had wondered:
+
+> Umm, don't "string types" have a bunch of extra semantics beyond just 
+> literals? In particular, string types can be static. Doesn't this 
+> cause some problems?
+
+to which Tucker responded:
+
+"Good point, we will have to look at that."
+
+But so far as I can tell, no one has. Hopefully someone will do that ASAP.
+
+(9) I had suggested eliminating the Implementation Permission completely 
+(replacing it with an Implementation Note suggesting the use of as-if 
+optimizations and applying the permission to call a function with 
+Global => null only once), since it doesn't allow anything that isn't already 
+allowed for any Global => null function. (At least, I've been assuming that 
+there is a rule similar to the one for functions in Pure packages that applies
+to such functions -- they have similar purposes -- if not, we should fix 
+AI12-0079-1, not this AI!)
+
+Tucker had replied that "he was convinced", but the permission remains. We 
+actually discussed it a bit during the meeting, so I don't want to delete it
+without getting the OK from this list.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent