!standard 4.5.2(9.3/2) 06-11-10 AI05-0020-1/01 !standard 4.5.5(19.2/2) !class binding interpretation 06-11-10 !status work item 06-11-10 !status received 06-08-26 !priority Medium !difficulty Easy !qualifier Omission !subject Operators of Partial views of fixed point and access types are considered !summary Operators of partial views of fixed point and access types (if any) are considered when determining if the predefined universal_fixed and universal_access operators can be used. !question The rules in 4.5.2(19.1-19.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 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. 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 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. !corrigendum 4.5.2(9.3/2) @drepl @xbullet; and> @dby @xbullet or any partial 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 Leory 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"). ****************************************************************