Version 1.6 of ai05s/ai05-0020-1.txt
!standard 4.5.2(9.3/2) 07-05-25 AI05-0020-1/03
!standard 4.5.5(19.2/2)
!class binding interpretation 06-11-10
!status Amendment 201Z 08-11-26
!status WG9 Approved 07-06-29
!status ARG Approved 9-0-2 06-11-18
!status work item 06-11-10
!status received 06-08-26
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Universal operators of fixed point and access types
!summary
Operators of partial views of fixed point types are considered when determining
if the predefined universal_fixed operators can be used. Similarly, if equality
is defined for an anonymous access type with a designated type of a partial or
incomplete view, then that equality operator is considered when determining if
the predefined universal_access operator can be used.
!question
The rules in 4.5.2(9.1-9.4/2) specify when the universal_access "=" operator
can be used. These rules have rather counter-intuitive consequences.
Consider the example:
package P is
type T is private;
function "=" (L, R : access T) return Boolean;
private
type T is null record;
end P;
for clients of P, which see the partial view of T, the presence of the
user-defined "=" in the visible part has the effect of eliminating the
"=" for universal_access during overload resolution, and therefore
equality among values of "access T" unambiguously use P."=" (assuming it's
visible). Fine, this is presumably what the author of the package
intended.
But consider what happens after the completion of T (including in the
body of P, in its private children, etc.). The view of T that is now
visible is the full view, and there is no user-defined "=" declared in the
same declaration list (the private part). So now equality among values of
"access T" is ambiguous because the "=" for universal_access is not
eliminated. In order to force usage of the user-defined "=", you have to
write P."=", even though you are inside of P.
This is silly and counter-intuitive. It seems that the rule ought to say
that, if the view under consideration is declared in a private part, the
entire package specification must be scanned for user-defined operators.
Fixed point types have similar rules and a similar example can be constructed
for them.
!recommendation
(See summary.)
!wording
Modify 4.5.2(9.3/2) to:
* it is declared immediately within the same declaration list as D{ or
any partial or incomplete view of D}; and
Modify 4.5.5(19.2/2) to:
* it is declared immediately within the same declaration list as the type{ or
any partial view thereof}; and
!discussion
Surely any operators declared on the partial view need to be considered. This
was just an oversight of the original wording, probably because completing
private types with a fixed point type isn't very common.
For "=", the problem can also occur for incomplete types:
type Incomp;
function "=" (Left, Right : access Incomp);
This is perfectly fine, and we don't want the completion to act differently just
because there is an incomplete view.
This latter case can't happen for fixed-point types, because use of an untagged
incomplete type as a non-access parameter is prohibited:
function "*" (Left, Right : Incomp); -- Illegal!
!corrigendum 4.5.2(9.3/2)
Replace the paragraph:
- it is declared immediately within the same declaration list as D; and
by:
- it is declared immediately within the same declaration list as D or
any partial or incomplete view of D; and
!corrigendum 4.5.5(19.2/2)
Replace the paragraph:
- it is declared immediately within the same declaration list as the type; and
by:
- it is declared immediately within the same declaration list as the type or
any partial view thereof; and
!ACATS test
Make a pair of C-Tests similar to the example.
!appendix
From: Pascal Leroy
Date: Saturday, August 26, 2006 4:46 AM
The Amendment defines (in AI 364 and AI 420) new name resolution rules
that are intended to make usages of some user-defined operators
unambiguous despite the presence of operators for universal_access and
universal_fixed in Standard. Both rules (4.5.2(9.1-9.3) and
4.5.5(19.1-19.4)) work in a very similar fashion, and they focus on
user-defined operators "declared immediately within the same declaration
list as" the type.
This phrase puzzles me. First, I assume that this is one of the many
cases where the word "type" should be interpreted to mean "view of the
type". Otherwise, for a type with two views it is unclear what
declaration list should be considered.
But more importantly, this rule has rather counter-intuitive consequences.
Consider the example:
package P is
type T is private;
function "=" (L, R : access T) return Boolean;
private
type T is null record;
end P;
For clients of P, which see the partial view of T, the presence of the
user-defined "=" in the visible part has to the effect of eliminating the
"=" for universal_access during overload resolution, and therefore
equality among values of "access T" unambiguously use P."=" (assuming it's
visible). Fine, this is presumably what the author of the package
intended.
But consider what happens *after* the completion of T (including in the
body of P, in its private children, etc.). The view of T that is now
visible is the full view, and there is no user-defined "=" declared in the
same declaration list (the private part). So now equality among values of
"access T" is ambiguous because the "=" for universal_access is *not*
eliminated. In order to force usage of the user-defined "=", you have to
write P."=", even though you are inside of P.
This is silly and counter-intuitive. It seems that the rule ought to say
that, if the view under consideration is declared in a private part, the
entire package specification must be scanned for user-defined operators.
Of course, it is possible to build a similar example for fixed-point
operators:
package P is
type T is private;
function "*" (L, R : T) return T;
private
type T is delta 1.0 range 0.0..42.0;
-- A call to "*" is ambiguous here.
end P;
****************************************************************
From: Tucker Taft
Date: Saturday, August 26, 2006 12:50 PM
I suspect this problem arose because the original
rules related to types which didn't typically have multiple
views (fixed-point types), though as you point out,
it is possible to complete a private type with a
fixed-point type. We could say "declared immediately
within the same declaration list as the type, or
partial view thereof."
****************************************************************
From: Pascal Leroy
Date: Monday, August 28, 2006 2:31 AM
Yes, that would work (and it's always nice to use "thereof").
****************************************************************
Questions? Ask the ACAA Technical Agent