CVS difference for 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
!class Amendment 18-01-22
@@ -16,7 +16,7 @@
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