CVS difference for ai05s/ai05-0052-1.txt
--- ai05s/ai05-0052-1.txt 2008/02/05 06:33:09 1.5
+++ ai05s/ai05-0052-1.txt 2008/03/07 06:15:19 1.6
@@ -1,6 +1,7 @@
-!standard 4.8(5.3/2) 08-02-04 AI05-0052-1/04
-!standard 7.5(6.1/2)
+!standard 4.8(5.3/2) 08-02-24 AI05-0052-1/05
+!standard 7.5(8/2)
!class binding interpretation 07-05-15
+!status ARG Approved 7-0-1 08-02-09
!status work item 07-05-15
!status received 07-05-14
!priority Medium
@@ -10,15 +11,20 @@
!summary
-An allocator that is used to create a coextension is illegal if
-the designated type might be limited but the enclosing object is not
-inherently limited.
+Statically reject an allocator used to create a coextension if
+the designated type is limited but the enclosing object might be
+of a nonlimited type.
-The term "inherently limited type" is (re-)introduced to simplify the
+The term "immutably limited type" is introduced to simplify the
presentation of this and other legality rules.
+All of the legality rules of 4.8 apply in the private part of
+an instance.
+
!question
+First:
+
In the case of a call to a function with a class-wide nonlimited
result type, or of a dispatching call to a function with a nonlimited
controlling result type, the current language definition seems
@@ -31,48 +37,105 @@
Was this intended?
+Second, in an apparently unrelated topic:
+
+In an instance, 12.3(11) says that the Legality Rules are normally
+checked in the visible part of an instance, but not the private part.
+However, there are lots of Legality Rules that the RM says are also
+checked in the private part.
+
+Should 4.8(5.1) be one of those? It looks like a possible oversight
+that it isn't.
+
+ package Pak1 is
+
+ type Root is tagged null record;
+ type Root_Acc is access all Root'Class;
+
+ generic
+ type T is new Root with private;
+ Init : T;
+ package Gen_Pack is
+ private
+ X : Root_Acc := new T' (Init);
+ end Gen_Pack;
+
+ end Pak1;
+
+
+ with Pak1;
+ procedure Proc1 is
+ type Child is new Pak1.Root with record ... end record;
+ Child_Init : constant Child := ...;
+ package Inst is new Pak1.Gen_Pack (Child, Child_Init);
+ begin
+ ...
+ end Proc1;
+
+With the current wording of the Standard, it appears that the instance
+would be illegal if X were in the visible part of Gen_Pack; but with X
+in the private part, the program is legal but will raise an exception
+at runtime. There doesn't seem to be a good reason for this difference.
+
!recommendation
-Statically reject an allocator used to create a coextensions if
-the designated type might be limited but the enclosing object might be
-of a nonlimited type.
+(See summary.)
!wording
-Add after 4.8(5.3/2):
+Modify 4.8(5.3/2) as follows:
-If the designated type of the type of the allocator is limited, then
-the allocator shall not be used to define the discriminant of an
-object, unless the object is of an inherently limited type (see 7.5).
+An allocator shall not be of an access type for which the Storage_Size
+has been specified by a static expression with value zero or is defined
+by the language to be zero. In addition to the places where Legality Rules
+normally apply (see 12.3), this rule applies also in the private part of
+an instance of a generic unit. This rule does not apply in the body of
+a generic unit or within a body declared within the declarative region
+of a generic unit, if the type of the allocator is a descendant of a
+formal access type declared within the formal part of the generic unit.
+
+{If the designated type of the type of the allocator is limited, then
+the allocator shall not be used to define the value of an access
+discriminant, unless the discriminated type is immutably limited (see 7.5).}
-AARM Note: Because coextensions work very much like parts, we don't want
+{AARM Note: Because coextensions work very much like parts, we don't want
users creating limited coextensions for nonlimited types. This would
be similar to extending a nonlimited type with a limited component. We
check this on the allocator. Note that there is an asymmetry in what
types are considered limited; this is required to preserve privacy. We
have to assume that the designated type might be limited as soon as we
see a limited partial view, but we want to ensure that the containing
-object is of a truly limited type.
+object is of a type that is always limited.}
-Add after 7.5 (6.1/2):
-
-A view of a type is inherently limited if it is one of the following:
-
-* An explicitly limited record;
-
-* A tagged limited private type;
-
-* A task type, a protected type, or a synchronized interface;
+{In addition to the places where Legality Rules
+normally apply (see 12.3), these rules apply also in the private part
+of an instance of a generic unit.}
+
+Add after 7.5 (8/2):
-* A type derived from an inherently limited type;
+A type is *immutably limited* if it is one of the following:
+
+* A descendant of an explicitly limited record type;
+
+* A descendant of a non-formal tagged limited private type;
-* A type with a part that is of a inherently limited type.
+* A descendant of a task type, a protected type, or a synchronized interface;
+
+* A descendant of a formal limited private type, except within the body of a generic unit
+ or a body declared within the declarative region of a generic unit, if the type is
+ declared within the formal part of the generic unit;
+
+* A type with a part that is of an immutably limited type.
-AARM note: an inherently limited type is a type that cannot become nonlimited
+AARM Discussion: An immutably limited type is a type that cannot become nonlimited
subsequently in a private part or in a child unit. If a view of the type
-makes it inherently limited, then no assignment or copying operations
-are ever available for objects of the type, and it is safe for such objects
-to have access discriminants that designate other limited objects.
+makes it immutably limited, then no copying (assignment) operations
+are ever available for objects of the type. This allows other properties;
+for instance, it is safe for such objects to have access discriminants that
+have defaults or designate other limited objects.
+
+AARM Ramification: A limited interface is not immutably limited; a type derived
+from it can be non-limited.
!discussion
@@ -165,6 +228,71 @@
and the type with the discriminant is not known to be limited (usually a limited
private type.) Coextension use is rare enough that this is not that important.
+
+For the second question, we note that would need to check the new rule in the
+private part of an instance, and 4.8(5.3/2) already has such a rule.
+
+The example in the question makes it clear that 4.8(5.1/2) also should be checked
+in the private part. There doesn't seem to be any benefit in postponing detection
+of an error from compile-time to run-time.
+
+4.8(5.2/2) should also apply in the private part of an instance, for similar
+reasons to 4.8(5.1/2), and also just to avoid confusion of having different
+policies apply to different legality rules for a single entity (in this case,
+an allocator).
+
+So, we factor out the "applies in the private part of an instance" wording into
+a separate pargraph that applies to all of the legality rules of 4.8.
+
+
+!corrigendum 4.8(5.3/2)
+
+@drepl
+An @fa<allocator> shall not be of an access type for which the Storage_Size
+has been specified by a static expression with value zero or is defined by
+the language to be zero. In addition to the places where Legality Rules
+normally apply (see 12.3), this rule applies also in the private part
+of an instance of a generic unit. This rule does not apply in the body
+of a generic unit or within a body declared within the declarative region
+of a generic unit, if the type of the allocator is a descendant of a
+formal access type declared within the formal part of the generic unit.
+@dby
+An @fa<allocator> shall not be of an access type for which the Storage_Size
+has been specified by a static expression with value zero or is defined by
+the language to be zero. This rule does not apply in the body
+of a generic unit or within a body declared within the declarative region
+of a generic unit, if the type of the allocator is a descendant of a
+formal access type declared within the formal part of the generic unit.
+
+If the designated type of the type of the @fa<allocator> is limited, then
+the @fa<allocator> shall not be used to define the value of an access
+discriminant, unless the discriminated type is immutably limited (see 7.5).
+
+In addition to the places where Legality Rules
+normally apply (see 12.3), these rules apply also in the private part
+of an instance of a generic unit.
+
+
+!corrigendum 7.5(8/2)
+
+@dinsa
+There are no predefined equality operators for a limited type.
+@dinss
+A type is @i<immutably limited> if it is one of the following:
+
+@xbullet<A descendant of an explicitly limited record type;>
+
+@xbullet<A descendant of a non-formal tagged limited private type;>
+
+@xbullet<A descendant of a task type, a protected type, or a synchronized interface;>
+
+@xbullet<A descendant of a formal limited private type, except within the body of a
+generic unit or a body declared within the declarative region of a generic unit,
+if the type is declared within the formal part of the generic unit;>
+
+@xbullet<A type with a part that is of an immutably limited type.>
+
+
!ACATS test
An ACATS B-Test is needed to check this rule.
@@ -199,6 +327,111 @@
As such, I don't see much point in adding a restriction here. But I realize that
other implementations may have much more serious issues. Net-net: I can't endorse
anything for this issue.
+
+****************************************************************
+
+!topic Should 4.8(5.1) be checked in the private part of an instance?
+!reference RM05 4.8(5.1), 12.3(11)
+!from Adam Beneschan 08-01-10
+!discussion
+
+In an instance, 12.3(11) says that the Legality Rules are normally
+checked in the visible part of an instance, but not the private part.
+However, there are lots of Legality Rules that the RM says are also
+checked in the private part.
+
+Should 4.8(5.1) be one of those? It looks like a possible oversight
+that it isn't.
+
+ package Pak1 is
+
+ type Root is tagged null record;
+ type Root_Acc is access all Root'Class;
+
+ generic
+ type T is new Root with private;
+ Init : T;
+ package Gen_Pack is
+ private
+ X : Root_Acc := new T' (Init);
+ end Gen_Pack;
+
+ end Pak1;
+
+
+ with Pak1;
+ procedure Proc1 is
+ type Child is new Pak1.Root with record ... end record;
+ Child_Init : constant Child := ...;
+ package Inst is new Pak1.Gen_Pack (Child, Child_Init);
+ begin
+ ...
+ end Proc1;
+
+It appears that the instance would be illegal if X were in the visible
+part of Gen_Pack; but with X in the private part, the program is legal
+but will raise an exception at runtime. There doesn't seem to be a
+good reason for this. (GNAT rejects this program, by the way.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 10, 2008 9:06 PM
+
+> In an instance, 12.3(11) says that the Legality Rules are normally
+> checked in the visible part of an instance, but not the private part.
+> However, there are lots of Legality Rules that the RM says are also
+> checked in the private part.
+
+I don't think there is much doubt that we got the default wrong on this; it
+should always be checked in the private part unless there is a rule that
+says it is not. But it is waaayyy too late to make that kind of change.
+
+> Should 4.8(5.1) be one of those? It looks like a possible oversight
+> that it isn't.
+
+Most certainly. There are probably only a handful of rules in the entire
+standard that it shouldn't apply to. Of course, there are many where it does
+not matter either way.
+
+> package Pak1 is
+>
+> type Root is tagged null record;
+> type Root_Acc is access all Root'Class;
+>
+> generic
+> type T is new Root with private;
+> Init : T;
+> package Gen_Pack is
+> private
+> X : Root_Acc := new T' (Init);
+> end Gen_Pack;
+>
+> end Pak1;
+>
+>
+> with Pak1;
+> procedure Proc1 is
+> type Child is new Pak1.Root with record ... end record;
+> Child_Init : constant Child := ...;
+> package Inst is new Pak1.Gen_Pack (Child, Child_Init);
+> begin
+> ...
+> end Proc1;
+>
+> It appears that the instance would be illegal if X were in the visible
+> part of Gen_Pack; but with X in the private part, the program is legal
+> but will raise an exception at runtime. There doesn't seem to be a
+> good reason for this. (GNAT rejects this program, by the way.)
+
+I suspect GNAT is just following good sense here.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, January 11, 2008 1:35 AM
+
+I can't verify this, but I suspect that the IBM compiler also rejects this code.
****************************************************************
Questions? Ask the ACAA Technical Agent