!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) @drepl @xbullet; and> @dby @xbullet or any partial or incomplete view of @i; and> !corrigendum 4.5.5(19.2/2) @drepl @xbullet @dby @xbullet !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"). ****************************************************************