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

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

--- ai12s/ai12-0249-1.txt	2018/12/14 08:31:30	1.6
+++ ai12s/ai12-0249-1.txt	2019/01/25 23:22:54	1.7
@@ -1,4 +1,4 @@
-!standard 4.2(9)                                     18-12-10  AI12-0249-1/04
+!standard 4.2(9)                                     19-01-25  AI12-0249-1/05
 !standard 4.2.1(0)
 !standard 4.9(3)
 !class Amendment 18-01-22
@@ -16,7 +16,7 @@
 !problem
 
 As we see an increasing interest in abstract data types such as
-containers, unbounded strings, "bignums," etc., the inability to use
+containers, unbounded strings, "bignums", etc., the inability to use
 literals with these types becomes more evident. In some cases, an
 operator such as unary "+" can be "hijacked" to provide for literals,
 but it always feels to be a bit of a kludge, and may require some kind
@@ -34,8 +34,8 @@
 single type or allow the expected type to be any type in a class, so long 
 as the 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
+Since no types currently have literal aspects, there is no immediate
+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.
 
@@ -174,11 +174,20 @@
   floating point type that would allow the use of string literals
   for certain special values like "NaN" or "+inf".
 
-  For the purposes of this rule, we treated all numeric literals
+  For the purposes of this Legality Rule, we treated all numeric literals
   as one "kind" of literal, and disallow any numeric type from having
   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.
+
+* For other purposes than the Legality Rule noted above, we have two kinds 
+  of numeric literals to match the lexical rules of the language, and to 
+  allow compile-time rejection of the "wrong" kind of numeric literal when 
+  both are not desired. For instance, a Big Integer package probably does 
+  not want to allow real literals (that is, literals with decimal points).
+  Leaving this detection to runtime (meaning that an exception may be 
+  raised) increases the chance that a mistake in a little-used piece of
+  code could cause a failure.
 
 * We have decided not to use this feature for existing language-defined
   packages (such as Unbounded_Strings). We believe it would be safer to

Questions? Ask the ACAA Technical Agent