--- 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