CVS difference for ais/ai-00364.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00364.txt

--- ais/ai-00364.txt	2004/03/03 00:21:34	1.6
+++ ais/ai-00364.txt	2004/06/08 02:50:59	1.7
@@ -1,4 +1,4 @@
-!standard  04.05.05(20)                                04-02-29  AI95-00364/01
+!standard  04.05.05(20)                                04-06-07  AI95-00364/02
 !class amendment 03-12-04
 !status work item 04-02-29
 !status received 03-09-29
@@ -37,14 +37,14 @@
 
    The above two fixed-fixed multiplying operators shall not be used in a
    context where the expected type for the result is itself universal_fixed
-   -- [the context has to identify some other numeric type to which the
+   [-- the context has to identify some other numeric type to which the
    result is to be converted, either explicitly or implicitly]. {An
    explicit conversion is required on the result when using the above
-   fixed-fixed multiplication operator when both operands are of types with
-   user-defined primitive fixed-fixed multiplication operators. Similarly,
-   an explicit conversion is required on the result when using the above
-   fixed-fixed division operator when both operands are of types with
-   user-defined primitive fixed-fixed division operators.}
+   fixed-fixed multiplication operator when either operand is of a type having
+   a user-defined primitive multiplication operator declared immediately
+   within the same list of declarations as the type and with both formal
+   parameters of a fixed-point type. A corresponding requirement applies to
+   the universal fixed-fixed division operator.}
 
      {AARM NOTE: We have made these into Name Resolution rules (one of them
      existed in Ada95 but as a Legality Rule) to ensure that user-defined
@@ -57,15 +57,15 @@
 After taking a shot at defining the universal-access equality operators in
 standard, it became obvious that there is a simple fix for the
 universal-fixed incompatibility. Just have a name-resolution rule which
-forbids use of the universal-fixed operations if both operand types have at
+forbids use of the universal-fixed operations if either operand type has at
 least one primitive user-defined multiply operator, in the case of the
-univ-fixed multiply op, or both have at least one primitive user-defined
+univ-fixed multiply op, or either has at least one primitive user-defined
 divide operator in the case of the univ-fixed divide op.
 
 This doesn't have any beaujolais effects, because it isn't a preference
 rule. Just certain fixed-point type combinations can't be used with the
-universal-fixed multiply/divide operators, based strictly on whether they
-both have their own primitive multiply/divide operators, even where these
+universal-fixed multiply/divide operators, based strictly on whether one
+of them has its own primitive multiply/divide operators, even when these
 primitive operators are *not* visible.
 
 Note that we still allow the universal-fixed operators to be considered
@@ -78,17 +78,16 @@
 universal-fixed operator if the operand types correspond to types
 for which there is a visible user-defined operator.
 
-OPEN ISSUE:
-  I phrased the suggested rule as requiring "both" to have a user-defined
-  primitive operator, but it could be phrased as "either." "Both" makes
-  sense if multiple fixed-point types are defined in the same scope.
-  "Either" makes sense if fixed-point types tend to be defined each in
-  their own package, because the "first" one defined would likely not have
-  any operators of its own. Compatibility with Ada 83 is enhanced by
-  specifying "either."  Compatibility with Ada 95 is enhanced by specifying
-  "both."  Because explicit conversion is always available as a fall back,
-  perhaps "either" is preferable, since it has less dependence on the
-  structure of the packages defining the fixed-point types.
+Note that the proposed rule specifies that "either" needs to have a
+user-defined primitive operator, but it could be phrased as "both."
+"Both" makes sense if multiple fixed-point types are defined in the same
+scope. "Either" makes sense if fixed-point types tend to be defined each
+in their own package, because the "first" one defined would likely not
+have any operators of its own. Compatibility with Ada 83 is enhanced by
+specifying "either."  Compatibility with Ada 95 is enhanced by
+specifying "both."  Because explicit conversion is always available as a
+fall back, "either" seems preferable, since it has less dependence on
+the structure of the packages defining the fixed-point types.
 
 This isn't a totally hypothetical problem. At one point we definitely
 dealt with a customer who was trying to figure out how to get their old Ada

Questions? Ask the ACAA Technical Agent