CVS difference for ais/ai-00230.txt
--- ais/ai-00230.txt 2005/08/21 06:00:15 1.26
+++ ais/ai-00230.txt 2005/10/31 05:18:12 1.27
@@ -1,6 +1,7 @@
-!standard 03.04.01(06) 05-08-08 AI95-00230/18
+!standard 03.04.01(06) 05-09-30 AI95-00230/19
!standard 03.02.01(07)
!standard 03.02.01(08)
+!standard 03.04.01(03)
!standard 03.04.01(10)
!standard 03.06(07)
!standard 03.06(22/1)
@@ -164,6 +165,15 @@
or an anonymous type that is defined by {an access_definition or} as part
of declaring an object of the type, is called a *full type*. ...
+Change 3.4.1(3) as follows:
+
+ Every type is either a specific type, a class-wide type, or a universal type.
+ A specific type is one defined by a type_declaration, a
+ formal_type_declaration, or a full type definition embedded in [a declaration
+ for an object]{another construct}. Class-wide and universal types are
+ implicitly defined, to act as representatives for an entire class of types,
+ as follows:
+
Change 3.4.1(6) as follows:
Universal Types
@@ -296,9 +306,18 @@
normal access types.
Legality Rules
+
+ At least one of the operands of the equality operators for
+ universal_access shall be null, or both shall be
+ access-to-object types, or both shall be access-to-subprogram
+ types. Further:
+ * When both are access-to-object types, the
+ designated types shall be the same or one shall cover the
+ other, and if the designated types are elementary or array types,
+ then the designated subtypes shall statically match;
+ * When both are access-to-subprogram types,
+ the designated profiles shall be subtype conformant.
- The operands of the equality operators for universal_access shall be
- convertible to one another (see 4.6).
Change paragraph 4.6(13) as follows:
@@ -307,6 +326,10 @@
the operand type shall be {universal_access or} an access-to-object type.
Further{, if the operand type is not universal_access}:
+Add before 4.6(18):
+ If the target type is a pool-specific access-to-object type, then
+ the operand type shall be universal_access.
+
Change paragraph 4.6(18) as follows:
If the target type is an access-to-subprogram type, then the operand type
@@ -609,6 +632,22 @@
not separate types; they are partial or incomplete views
of some full type.
+!corrigendum 3.4.1(3)
+
+@drepl
+Every type is either a @i<specific> type, a @i<class-wide> type, or a
+@i<universal> type. A specific type is one defined by a @fa<type_declaration>,
+a @fa<formal_type_declaration>, or a full type definition embedded in a
+declaration for an object. Class-wide and universal types are implicitly
+defined, to act as representatives for an entire class of types, as follows:
+@dby
+Every type is either a @i<specific> type, a @i<class-wide> type, or a
+@i<universal> type. A specific type is one defined by a @fa<type_declaration>,
+a @fa<formal_type_declaration>, or a full type definition embedded in
+another construct. Class-wide and universal types are implicitly
+defined, to act as representatives for an entire class of types, as follows:
+
+
!corrigendum 3.4.1(6)
@drepl
@@ -887,8 +926,16 @@
@i<@s8<Legality Rules>>
-The operands of the equality operators for @i<universal_access> shall be
-convertible to one another (see 4.6).
+At least one of the operands of the equality operators for
+@i<universal_access> shall be null, or both shall be
+access-to-object types, or both shall be access-to-subprogram
+types. Further:
+@xbullet<When both are access-to-object types, the
+designated types shall be the same or one shall cover the
+other, and if the designated types are elementary or array types,
+then the designated subtypes shall statically match;>
+@xbullet<When both are access-to-subprogram types,
+the designated profiles shall be subtype conformant.>
!corrigendum 4.6(13)
@@ -909,6 +956,9 @@
If the target type is an access-to-subprogram type, then the operand type
shall be an access-to-subprogram type. Further:
@dby
+@xbullet<If the target type is a pool-specific access-to-object type, then
+the operand type shall be @i<universal_access>.
+
If the target type is an access-to-subprogram type, then the operand type
shall be @i<universal_access> or an access-to-subprogram type. Further, if
the operand type is not @i<universal_access>:
@@ -2556,6 +2606,174 @@
"We also fix an RM bug here; 3.4.1(3) says that all types are either specific,
class-wide, or universal, but then fails to include access_definition (for
anonymous access types) in any of those categories."
+
+*************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005 12:38 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+6.1(15/2):
+
+15/2 {AI95-00231-01} parameter_specification ::=
+ defining_identifier_list : mode [null_exclusion] subtype_mark
+ [:= default_expression]
+ | defining_identifier_list : access_definition
+ [:= default_expression]
+
+Why do we disallow access parameters of modes 'in out' or 'out'?
+We've gone to all this trouble to allow anonymous access types everywhere, but
+here's a case where programmer's will have to declare a named access type.
+
+Are there any other cases where the name of an access type is allowed, but an
+access definition is not?
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 6, 2005 7:27 PM
+
+Groan. I think there could be some significant
+implementation issues and possible dangling-reference
+possibilities with writable access parameters,
+since their accessibility level is dynamic.
+I also find the idea of "out access constant D"
+pretty painful to imagine, bordering on the
+C++ "const" nightmare. I think we would be
+asking for trouble to introduce these at this
+late date.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 6, 2005 9:59 PM
+
+> Why do we disallow access parameters of modes 'in out' or 'out'?
+
+I don't know, ask the Ada 9X team. :-) They were requested several times, I
+believe.
+
+> We've gone to all this trouble to allow anonymous access types everywhere, but
+> here's a case where programmer's will have to declare a named access type.
+
+As Tucker points out, they would be a real mess to allow, mainly because of
+accessibility. Of course, the only reason we need these special properties
+are because some people wouldn't allow "in out" parameters (at least for
+tagged types) in functions. But that will never be fixed, and thus we're
+stuck with this abomination.
+
+> Are there any other cases where the name of an access type is allowed, but an
+> access definition is not?
+
+A type conversion or qualification, of course. And I can hardly imagine
+trying to fix that! Imagine:
+
+ List := not null access constant T(Func(A, B));
+
+John's work on the Rationale shows that you need named types in various
+cases not having to do with parameter passing, in part because the implicit
+conversions are only allowed when the checks cannot fail. And there are
+enough cases where the checks *could* fail that I think most stuff will end
+up using named types anyway.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005 3:34 AM
+
+> Why do we disallow access parameters of modes 'in out' or
+> 'out'?
+
+Arrrgh! Don't even think of it at this late stage.
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, June 7, 2005 12:37 PM
+
+> John's work on the Rationale shows that you need named types in various
+> cases not having to do with parameter passing, in part because the implicit
+> conversions are only allowed when the checks cannot fail. And there are
+> enough cases where the checks *could* fail that I think most stuff will end
+> up using named types anyway.
+
+This comment of Randy's caught my eye. Specifically, I'm wondering about
+the part that says "implicit conversions are only allowed when the checks
+cannot fail." What does that follow from? In the process of considering
+accessibility checks needed for the new entities that can have an anonymous
+access type I was looking at cases such as the following:
+
+ A : access Integer := ...;
+
+ procedure Proc (X : access Integer) is
+ begin
+ A := X;
+ end Proc;
+
+If the above assignment is legal then it clearly requires a run-time check.
+Is there a rule I'm missing that makes the assignment illegal?
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 7, 2005 1:49 PM
+
+> This comment of Randy's caught my eye. Specifically, I'm wondering about
+> the part that says "implicit conversions are only allowed when the checks
+> cannot fail." What does that follow from?
+
+That's the basic principle of implicit conversions, as explained by Tucker.
+
+> In the process of considering accessibility checks needed for the new
+> entities that can have an anonymous access type I was looking at cases
+> such as the following:
+>
+> A : access Integer := ...;
+>
+> procedure Proc (X : access Integer) is
+> begin
+> A := X;
+> end Proc;
+>
+> If the above assignment is legal then it clearly requires a run-time check.
+> Is there a rule I'm missing that makes the assignment illegal?
+
+I can't find one, which means either that the "basic principle" is garbage
+(which makes me wonder why we don't allow tag checks in this case), or its
+missing (which would make things less usable, of course). I don't see much
+difference between tag checks and accessibility checks.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, June 7, 2005 3:30 PM
+
+I think I must have been dreaming.
+
+Imnplicit conversions are a result of the overload
+resolution rules. They allow a particular "actual"
+type to match a particular "expected" type.
+The rules do not allow "downward" (narrowing)
+implicit conversions. They say nothing
+about accessibility.
+
+4.6(17,20) (in the Ada *95* RM) disallow conversions
+(implicit or explicit) when the static accessibility check
+fails, but allow anonymous-to-anonymous
+"implicit" conversion when a run-time check is required.
+
+In fact, this already happens in Ada 95 in the following:
+
+ type T(access Integer) is limited null record;
+ type Acc_T is access T;
+ function New_T(X : access Integer) return Acc_T is
+ begin
+ return new T(X); -- accessibility check on implicit
+ -- acc type conversion
+ end New_T;
+
+So I was obviously confused.
*************************************************************
Questions? Ask the ACAA Technical Agent