CVS difference for ai12s/ai12-0109-1.txt
--- ai12s/ai12-0109-1.txt 2014/05/17 01:32:18 1.2
+++ ai12s/ai12-0109-1.txt 2014/11/18 06:52:29 1.3
@@ -1,5 +1,7 @@
-!standard 13.1(10/3) 14-05-15 AI05-0109-1/01
+!standard 13.1(10/3) 14-11-14 AI05-0109-1/02
!class binding interpretation 14-05-15
+!status Corrigendum 2015 14-11-14
+!status ARG Approved 7-0-1 14-10-19
!status work item 14-05-15
!status received 14-03-16
@@ -65,45 +67,30 @@
-Add after 13.1(10/3):
+Add at the end of 13.1(10/3):
Similarly, it is illegal to specify a non-confirming
- type-related representation aspect for an untagged type
- after one or more types have been derived from it, if:
- * the type is a by-reference type; or
- * the aspect is Small or Machine_Radix, and
- any user-defined primitive subprograms were
- inherited by the derived types.
+ type-related representation aspect for an untagged by-reference type
+ after one or more types have been derived from it.
-AARM Discussion: By-reference type usually cannot be used in legality rules,
+AARM Discussion: "By-reference type" usually cannot be used in legality rules,
as it is privacy breaking. Our use here is privacy breaking, but we're stuck
with it for compatibility reasons. Since representation aspects cannot be
-specified on partial views, privacy breaking only happens when a type includes
-a component of a private type. In that case, whether these rules are triggered
-depends on the full type of the private type -- which is clearly privacy
+specified on partial views, privacy violations can only happen when a type
+includes a component of a private type. In that case, whether these rules
+are triggered depends on the full type of the private type -- which is
+clearly privacy breaking.
-AARM Reason: The first bullet prevents the need to generate impossible
+AARM Reason: The by-reference rules prevent the need to generate impossible
conversions between the derived types (a by-reference object cannot be copied
-to change its representation). The second bullet prevents implicit conversions
-that might lose precision (one way necessarily would do so).
+to change its representation).
-[Editor's note: I added the above because the use of the privacy-breaking
-term "by-reference type" should be both justified and called out.
-We could eliminate it by using a formulation similar to that in 4.6, where
-we use "limited", or have "a tagged, private, or volatile subcomponent" to avoid
-the privacy issues. That's probably too incompatible to do, unfortunately.]
Add after AARM 13.1(15.b.1/1): [a Ramification]
-If the aspect was specified by an aspect_specification and the parent type has
-not yet been frozen, then inherited aspect will not yet have been resolved and
-evaluated. The implementation will need to have a mechanism to handle such
-an aspect. (We believe that inheriting the unresolved and unevaluated aspect,
-and resolving it later at the normal point for the derived type, will give
-the same results as for the parent type in any legal program. Thus the
-implementation can be as if the aspect was directly specified for the derived
+If an aspect was specified by an aspect_specification and the parent type has
+not yet been frozen, then the inherited aspect will not yet have been resolved
+and evaluated. The implementation will need to have a mechanism to handle such
@@ -111,7 +98,7 @@
The rule 13.1(10/3) is a strange combination of a required semantic rule
and a methodological restriction. It is intended to prevent the need to
-make implicit conversions when calling inherited primitive subprogram.
+make implicit conversions when calling n inherited primitive subprogram.
In some cases (such as limited by-reference types), making a copy of an
object is prohibited and therefore it is impossible to make any implicit
@@ -123,7 +110,7 @@
are made both ways as for in out parameters). Here, a rule like 13.1(10/3) is
-Finally, there are cases where there is no semantic problem, the conversions
+Finally, there are cases where there is no semantic problem as the conversions
are semantics-preserving. These mainly are cases where the types have different
but equivalent representations, such as packed and unpacked versions of an
untagged record, or arrays with different component sizes. Here, 13.1(10/3)
@@ -164,9 +151,9 @@
It would be appealing to relax 13.1(10/3) to match the new rule. After all,
this provides a way to end-run 13.1(10/3), much like generics provided a
-way to end-run the no redefinition of "=" in Ada 83. However, that's going
+way to end-run the ban on redefinition of "=" in Ada 83. However, that's going
beyond the question of the AI, and some misguided people think that the
-methodological restriction is a good idea. Rather than pick a fight with them
+methodological restriction is a good idea.
An alternative fix would be to ban the derivation of an untagged type with
primitives in the same package. That would certainly fix the problem, but it
@@ -209,7 +196,7 @@
assume the simpler model (which would just reuse the existing aspect mechanism)
and see where it leads.
-There is clearly a possibility of anomolies given that the aspect has neither
+There is clearly a possibility of anomalies given that the aspect has neither
been resolved or evaluated at the point of the derived type (presuming that
no freezing point of the parent type has occurred).
@@ -242,17 +229,17 @@
+For an untagged derived type, it is illegal to specify a type-related
+representation aspect if the parent type is a by-reference type, or has any
+user-defined primitive subprograms.
For an untagged derived type, it is illegal to specify a type-related
representation aspect if the parent type is a by-reference type, or has any
user-defined primitive subprograms.
Similarly, it is illegal to specify a non-confirming
-type-related representation aspect for an untagged type
-after one or more types have been derived from it, if:
-@xbullet<the type is a by-reference type; or>
-@xbullet<the aspect is Small or Machine_Radix, and any user-defined primitive
-subprograms were inherited by the derived types.>
+type-related representation aspect for an untagged by-reference type
+after one or more types have been derived from it.
@@ -260,7 +247,10 @@
-An ACATS B-Test should be created to check the new rule.
+An ACATS B-Test should be created to check the new rule. It probably should
+have the form of the example found in the mail, so that it is clear why the
+(nasty) check is needed. An ACATS C-Test that the end-run around 13.1(10/3)
+works in cases that are not by-reference would also be valuable.
Questions? Ask the ACAA Technical Agent