CVS difference for ais/ai-00230.txt

Differences between 1.26 and version 1.27
Log of other versions for file 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