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

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

--- ai12s/ai12-0066-1.txt	2015/11/18 01:23:00	1.5
+++ ai12s/ai12-0066-1.txt	2017/04/21 05:43:52	1.6
@@ -1,4 +1,5 @@
-!standard 4.4(7/3)                                 13-12-18  AI12-0066-1/01
+!standard 3.2.4(21/3)                               17-04-13  AI12-0066-1/02
+!standard 4.4(7/3)
 !standard 8.5.1(6)
 !standard A.10.8(8)
 !standard A.10.9(13)
@@ -62,11 +63,27 @@
 parameter), as how could the body know what the parameters and defaults of the
 actual are? Something is wrong here.
 
+(5) The predicate-static rules (3.2.4(15-22/3) don't really work for a boolean
+subtype.
+
+Specifically, the predicate-static rules only allow the current-instance to be
+used as one of the operands of a relational operator, the operand of a
+membership, or the selector of a case expression. That means that the
+following are illegal:
+
+    subtype Fooey1 is Boolean with Static_Predicate => Fooey1; -- ERROR:
+    subtype Fooey2 is Boolean with Static_Predicate => Fooey2 or Debug; -- ERROR:
+
+In both of these cases, the current instance is not in one of the places
+allowed for a predicate-static expression.
+
+Should this be fixed?
+
 !response
 
 For these questions, we believe that adding proper wording to the Standard
-would be much more likely to introduce bugs than to clarify anything. These
-issues date to Ada 83, yet they've never been addressed.
+would be much more likely to introduce bugs than to clarify anything. Most of 
+these issues date to Ada 83, yet they've never been addressed.
 
 (1) There are some rules that say parenthesized expressions have no effect in
 specific cases (6.2(10/3) and 7.5(2.1/3) are examples of such rules). But
@@ -161,13 +178,13 @@
 
 We'd destroy the generic contract model if the body of the generic had to
 somehow know the parameter names and defaults of the actual. (That would be
-especially problematic if the actual had different names for the parameters.
+especially problematic if the actual had different names for the parameters.)
 
-So, we need to either (1) require full conformance when renaming or
-instantiating objects with access-to-subprogram types, or (2) adopt a rule
+So, we need to either (A) require full conformance when renaming or
+instantiating objects with access-to-subprogram types, or (B) adopt a rule
 like 8.5.4(7) for object renamings and formal in out parameters.
 
-(1) is easy but potentially incompatible; (2) is likely to be a significant
+(A) is easy but potentially incompatible; (B) is likely to be a significant
 amount of work. But the problematic case is rarely likely to happen in
 practice (generic formal in out parameters are rarely used; anonymous
 access-to-subprogram types are rarely used outside of parameters, that
@@ -175,6 +192,31 @@
 that we don't think it is worth fixing; the disruption to compilers outweighs
 any likely benefit to users.
 
+(5) The simple fix of just adding a bullet "the current instance" doesn't
+work because it would allow the current instance on the both sides of
+operators, which is not intended or desired. So a correct fix is relatively
+expensive.
+
+Moreover, there is an easy workaround to this problem: add "= True" to the
+expression:
+
+    subtype Fooey1 is Boolean with Static_Predicate => Fooey1 = True; -- OK.
+    subtype Fooey2 is Boolean with Static_Predicate => (Fooey2 = True) or Debug; -- OK.
+
+One also can easily write a range for any possible subtype; it's never
+necessary to use a static predicate in the way that it might for an
+enumeration type with more than 2 literals.
+
+Finally, a constrained subtype of a boolean type is essentially a pathology.
+Such a subtype is either the same as Boolean without the constraint, or is
+a subtype with zero or one values - something that is not going to be useful
+in conditional expressions or statements. (Such a subtype is essentially
+equivalent to a Boolean constant.)
+
+Since this is a relatively useless construct, and the wording needed is
+relatively complicated and only useful for this construct, we choose not to
+fix this.
+
 !appendix
 
 From: Randy Brukardt
@@ -225,7 +267,7 @@
 
 There's no such rule in 3.8, 4.1, 4.1.3, 8.2, 8.3, or 8.6. So where the heck
 is it? I find it hard to believe that there isn't any definition of this in
- the RM; it's been the rule since the beginning of time.
+the RM; it's been the rule since the beginning of time.
 
 Note that this also is necessary to define the meaning of the use of
 discriminants directly within type declarations (although there is no legality
@@ -952,3 +994,163 @@
 so just sticking it where the sun doesn't shine is as good as anything. :-)
 
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 11, 2017  9:39 PM
+
+I was just looking at the predicate-static rules for an unrelated reason, and
+it looks to me that they're too restrictive for a Boolean subtype.
+
+Specifically, the predicate-static rules only allow the current-instance to be
+used as one of the operands of a relational operator, the operand of a
+membership, or the selector of a case expression. That means that the
+following are illegal:
+
+    subtype Fooey1 is Boolean with Static_Predicate => Fooey1; -- ERROR:
+    subtype Fooey2 is Boolean with Static_Predicate => Fooey2 or Debug; -- ERROR:
+
+In both of these cases, the current instance is not in one of the places
+allowed for a predicate-static expression.
+
+One can make these legal by adding an equality operator:
+
+    subtype Fooey1 is Boolean with Static_Predicate => Fooey1 = True; -- OK.
+    subtype Fooey2 is Boolean with Static_Predicate => (Fooey2 = True) or Debug; -- OK.
+
+This sort of thing seems nearly pathological, and there is a (verbose)
+workaround, so I propose to file this comment into the AI of "things that we
+don't intend to fix" (AI12-0066-1). Any objections??
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, January 11, 2017  11:35 PM
+
+Why not fix it? Seems harmless, and clearly an omission. What annoys me if
+it's not fixed is that my own programming rules forbid the use of
+"= True/False", so I'm unconfortable with a case that requires it.
+
+The fix would be to add a bullet after 3.2.4(15/3) saying:
+- The current instance
+
+BTW, I notice that "Fooey1 = True" is NOT predicate-static, because
+3.2.4(20/3) says:
+- a call to a predefined boolean logical operator, where each operand is
+predicate-static;
+
+So, if "Fooey1" alone is not predicate-static, the comparison is not either!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 12, 2017  12:20 AM
+
+> Why not fix it? 
+
+Because a predicate on a Boolean type seems like a pathology to me. What
+possible use is there of a subtype with one value (or no values)? (And if
+the predicate does not disallow a value, then it's meaningless.) I don't
+want to spend ARG time fixing wording that only matters for pathologies.
+(Bob probably would say I err too far on fixing unimportant stuff as it is.)
+
+You could also make a case that:
+
+    subtype True_Only is Boolean with Static_Predicate => True_Only = True;
+
+is clearer than an alternative without the explicit "= True". (A direct test
+in such cases strikes me as tricky.)
+
+> Seems harmless, and clearly an omission. What annoys me if it's not 
+> fixed is that my own programming rules forbid the use of "= 
+> True/False", so I'm unconfortable with a case that requires it.
+
+A case that you'll never write??
+
+> The fix would be to add a bullet after 3.2.4(15/3) saying:
+> - The current instance
+
+That would allow some cases that we don't really want to allow (although I'm
+not sure any are really problems):
+
+    Fooey1 > Fooey1
+    Fooey1 or Fooey1
+    Fooey1 and then Fooey1
+
+and the like. The rules to this point only allow a single current instance on
+either side of an operator.
+
+In any case, the real question is whether to fix wording for a pathology.
+(Or can someone find a realistic use for such a predicate??)
+
+> BTW, I notice that "Fooey1 = True" is NOT predicate-static, because
+> 3.2.4(20/3) says:
+> - a call to a predefined boolean logical operator, where each operand 
+> is predicate-static;
+
+You're reading an ancient RM again (please get a newer one - I work hard to
+make these specifically so that we're all working with the latest wording).
+The corrigendum (AI12-0099-1) amended this bullet to say:
+
+* a call to a predefined boolean operator and, or, xor, or not, where each
+  operand is predicate-static;
+
+> So, if "Fooey1" alone is not predicate-static, the comparison is not 
+> either!
+
+The amended bullet makes it clear that 3.2.4(20/4) does not apply to "=".
+The bullet that applies is 3.2.4(19/3):
+
+* a call to a predefined equality or ordering operator, where one operand is
+  the current instance, and the other is a static expression;
+
+That clearly applies to "Fooey1 = True".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 28, 2017  12:23 AM
+
+Here's something "interesting" but we probably don't want to take any action.
+
+I tried to search for all of the places in the language were using a variable
+is required. Just looking for "variable" turned up 108 subclauses, so I needed
+a narrower search. But what? The wording isn't exactly consistent:
+
+3.10.2(25): "If A is an access-to-variable type, then the view shall be a
+variable; ..."
+
+4.1.3(13.2/2): "For a subprogram whose first parameter is of mode in out or
+out, or of an anonymous access-to-variable type, the prefix of any prefixed
+view shall denote a variable."
+
+5.2(5/2): "The target [denoted by the variable_name] shall be a variable of
+a nonlimited type."
+
+6.4.1(5): "If the mode is in out or out, the actual shall be a name that
+denotes a variable."
+
+9.5(7.1/3): "If a name or prefix determines a target object, and the name
+denotes a protected entry or procedure, then the target object shall be a
+variable, ..."
+
+12.4(7): "For a generic formal object of mode in out, the actual shall be a
+name that denotes a variable for which renaming is allowed (see 8.5.1)."
+
+13.11(15): "Storage_Size or Storage_Pool may be specified for a nonderived
+access-to-object type via an attribute_definition_clause; the name in a
+Storage_Pool clause shall denote a variable."
+
+13.11.3(5.2/4): "Otherwise, the expected type for the Default_Storage_Pool
+aspect is Root_Storage_Pool'Class and the aspect_definition shall be a name
+that denotes a variable."
+
+I gave up here, so I might have missed something with even stranger wording.
+
+If you're scoring at home, we have 3 "be a variable"s, 5 "denotes a
+variable"s, with two of the latter also using "be" in the wording ["be a
+name that denotes a variable"] while the other three don't use "be" at all.
+
+I love consistency like this. ;-)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent