CVS difference for ais/ai-00251.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2002/02/07 04:56:42	1.6
+++ ais/ai-00251.txt	2002/06/12 00:36:45	1.7
@@ -1,4 +1,4 @@
-!standard 03.04    (02)                            02-02-05  AI95-00251/03
+!standard 03.04    (02)                            02-06-05  AI95-00251/04
 !standard 03.09.01 (02)
 !class amendment 00-12-04
 !status work item 00-12-04
@@ -428,6 +428,203 @@
                 . . .
         end record;
 
+!wording
+
+[Editor's note: The discussion and proposal sections have not been updated
+to match this wording.]
+
+In 3.1 add
+
+    basic_declaration ::= ... | null_procedure_declaration
+
+
+In 3.2.1 add
+
+        type_definition ::= ... | abstract_interface_definition
+
+Replace 3.4(2)
+
+    derived_type_definition ::=
+        [ABSTRACT] NEW parent_subtype_indication
+        [record_extension_part]
+with
+    derived_type_definition ::=
+        [ABSTRACT] NEW parent_subtype_indication
+        [[AND abstract_interface_list] record_extension_part]
+
+Add after 3.4(23):
+    A type which implements an abstract interface (see 3.9.x) inherits
+    subprograms from the interface type, in the same way as for a type
+    derived from the interface type.
+
+Add between sentences 3 and 4 of 3.9(3):
+     The accessibilty level (see 3.10.2) of a type which implements an
+     abstract interface (see 3.9.4) shall not be statically deeper than
+     that of the interface type.
+
+Add after the first sentence 3.4.1(9):
+    If a type T1 implements an abstract interface type T2 (see 3.9.x),
+    then T2'Class also covers all types covered by T1'Class.
+
+Add after sentence 1 of 3.9(4):
+     An abstract interface shall not be
+     implemented in a generic body if the interface type is declared
+     outside that body.
+
+Add after 3.9.3(6):
+     Corresponding rules apply for a type which inherits an abstract
+     subprogram by implementing an abstract interface (see 3.9.x, 3.4).
+
+Add a new subclause after 3.9.3:
+Abstract Interface Types
+
+    An abstract interface type is an abstract tagged type intended for use
+    in providing a restricted form of multiple inheritance.
+    A tagged type may "implement" multiple interfaces, thereby allowing
+    multiple views of objects of the type.
+
+                             Syntax
+
+    abstract_interface_definition ::= ABSTRACT [LIMITED] INTERFACE
+
+    abstract_interface_list ::=
+        abstract_interface_subtype_mark
+        {AND abstract_interface_subtype_mark}
+
+                             Legality Rules
+
+    An abstract interface type (also called an "interface type" or
+    "interface") is a specific abstract tagged type that is defined by an
+    abstract_interface_definition, or by a derived_type_definition or
+    formal_derived_type_definition where the keyword ABSTRACT
+    appears and the parent type is an interface type.
+
+    An interface type shall have no components.
+
+    All primitive operations of an interface type shall be abstract
+    subprograms or null procedures.
+
+    The type of a subtype named in an abstract_interface_list shall be an
+        interface type.
+
+    A descendant of a type which names an interface type in an
+    abstract_interface_list, or which is derived from an interface type,
+    is said to "implement" the interface and all of its ancestors.
+    A class-wide type implements the interfaces implemented by the
+    corresponding specific type. The corresponding full view of a
+    partial view of a type implements all interfaces implemented by
+    the partial view.
+
+    A type which implements an interface shall be limited if and only
+    if the interface type is limited.
+
+    If a partial view defines an interface type, then the corresponding
+    full view shall define an interface type.
+
+    If a full view implements an interface, then the corresponding
+    partial view (if any) shall implement the interface.
+
+    For an interface type declared in a visible part, a primitive
+    subprogram shall not be declared in the private part.
+
+    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.
+
+Replace 4.6(21-23) with:
+
+  If the target type is tagged, then either:
+
+    The operand type shall be covered by or descended from the target type; or
+
+    The operand type shall be a class-wide type that covers the target type.
+
+  If the target type is not included in any of the above five cases,
+  there shall be a type that is an ancestor of both the target type and the
+  operand type.
+
+
+In 6.1 replace
+   subprogram_specification ::= PROCEDURE defining_program_unit_name
+                                          parameter_profile
+with
+   procedure_specification ::= PROCEDURE defining_program_unit_name
+                                         parameter_profile
+   subprogram_specification ::= procedure_specification
+
+Add a new subclause after 6.6:
+
+Null Procedures
+
+                              Syntax
+
+    null_procedure_declaration ::= procedure_specification IS NULL;
+
+                              Static Semantics
+
+    A null_procedure_declaration declares a null procedure.
+
+                              Dynamic Semantics
+
+    The execution of a null procedure is invoked by a subprogram call.
+    This execution has no effect.
+
+In 7.3, replace
+
+    private_extension_declaration ::=
+      type defining_identifier [discriminant_part] is
+      [ABSTRACT] NEW ancestor_subtype_indication WITH PRIVATE;
+with
+    private_extension_declaration ::=
+      type defining_identifier [discriminant_part] is
+      [ABSTRACT] NEW ancestor_subtype_indication
+      [[AND abstract_interface_list] WITH PRIVATE];
+
+Add after paragraph 8.3(12):
+
+    An implicit declaration of a subprogram which is neither abstract nor
+    a null procedure overrides that of a subprogram simultaneously
+    inherited by implementing an abstract interface.
+
+    If one subprogram overrides another and a type simultaneously inherits
+    subprograms corresponding to both, then the inherited subprogram
+    corresponding to the overriding subprogram overrides the other
+    inherited subprogram.
+
+    If an inherited subprogram corresponds to another subprogram and a
+    type simultaneously inherits subprograms corresponding to both, then
+    the subprogram corresponding to the inherited subprogram overrides the
+    other inherited subprogram.
+
+Add after paragraph 8.3(23):
+
+    If two non-overridden homographs are simultaneously inherited as
+    primitive operations of a tagged type which implements an abstract
+    interface, then they shall be fully conformant and either both shall
+    be abstract subprograms or both shall be null procedures.
+
+In 12.5.1, replace
+
+    formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
+                                       [WITH PRIVATE]
+with
+    formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
+                                       [[AND abstract_interface_list]
+                                       WITH PRIVATE]
+
+Add after 12.5.1(18);
+
+    If the formal type is an abstract interface type, then the actual type
+    shall be an abstract interface type.
+
+    The actual type shall implement any interfaces that are implemented by
+    the formal type.
+
+Add after paragraph 13.14(7):
+
+    The implementation of an abstract interface causes freezing of the
+    abstract interface type.
+
 !ACATS test
 
 !appendix
@@ -748,3 +945,724 @@
 one over the next couple of days.
 
 ****************************************************************
+
+From: Steve Baird
+Sent: Thursday, May 16, 2002  2:38 PM
+
+This is an initial proposal for wording for AI-00251 and some
+related issues (null procedures and unreserved keywords).
+    -- Steve
+
+----------------------------------------------------------------
+----------------------------------------------------------------
+
+Null procedures:
+
+    3.1
+
+    Add
+        basic_declaration ::= ... | null_procedure_declaration
+
+    --------
+
+   6.1
+
+   Replace
+       subprogram_specification ::= PROCEDURE defining_program_unit_name
+                                              parameter_profile
+   with
+       procedure_specification ::= PROCEDURE defining_program_unit_name
+                                             parameter_profile
+       subprogram_specification ::= procedure_specification
+
+   --------
+
+   6.7  Null Procedures
+
+                                  Syntax
+
+        null_procedure_declaration ::= procedure_specification IS NULL;
+
+                                  Static Semantics
+
+        A null_procedure_declaration declares a null procedure.
+
+                                  Dynamic Semantics
+
+        The execution of a null procedure is invoked by a subprogram call.
+        This execution has no effect.
+
+   --------
+
+Discussion:
+   1) Like an instantiation, a null procedure is not allowed as a
+completion.
+      Allowing this would double the amount of RM text needed.
+   2) A null procedure may have OUT-mode parameters, the same as a
+      conventional "begin null; end;" procedure.
+   3) Change Ada.Finalization spec to declare Initialize/Finalize/Adjust
+      as null procedures?
+
+----------------------------------------------------------------
+----------------------------------------------------------------
+
+Unreserved keywords (see AI-284):
+
+    2.2(1)
+      Replace "a reserved word," with "a keyword,"
+
+    2.3(4)
+      Replace
+         An identifier shall not be a reserved word.
+      with
+         An identifier shall not be a reserved keyword.
+
+    Replace 2.9 with:
+
+        2.9 Keywords
+
+                                  Syntax
+        The following are the reserved keywords (ignoring upper/lower case
+        distinctions):
+            ABORT ... XOR [same list as before]
+
+        The following are the unreserved keywords:
+            INTERFACE
+
+    Throughout the RM:
+        Replace "reserved word" with "keyword" (e.g. 3.9.3(2)).
+
+----------------------------------------------------------------
+----------------------------------------------------------------
+
+Abstract Interface Types
+
+    3.2.1
+
+    Add
+        type_definition ::= ... | abstract_interface_definition
+
+    --------
+
+    3.4(2)
+
+    Replace
+        derived_type_definition ::=
+            [ABSTRACT] NEW parent_subtype_indication
+            [record_extension_part]
+    with
+        derived_type_definition ::=
+            [ABSTRACT] NEW parent_subtype_indication
+            [[AND abstract_interface_list] record_extension_part]
+
+    --------
+
+    3.4
+
+    Add after paragraph 23:
+        A type which implements an abstract interface (see 3.9.4) inherits
+        subprograms from the interface type, in the same way as for a type
+        derived from the interface type.
+
+    --------
+
+    3.9.1
+
+    Add between sentences 3 and 4 of paragraph 3:
+         The accessibilty level (see 3.10.2) of a type which implements an
+         abstract interface (see 3.9.4) shall not be statically deeper than
+         that of the interface type.
+
+    Add after sentence 1 of paragraph 4:
+         An abstract interface shall not be
+         implemented in a generic body if the interface type is declared
+         outside that body.
+
+    --------
+
+    3.9.3
+
+     Add after paragraph 6:
+
+         Corresponding rules apply for a type which inherits an abstract
+         subprogram by implementing an abstract interface (see 3.9.4, 3.4).
+
+    --------
+
+    3.9.4 Abstract Interface Types
+
+        An abstract interface type is an abstract tagged type intended for
+use
+        in providing a restricted form of multiple inheritance.
+        A tagged type may "implement" multiple interfaces, thereby allowing
+        multiple views of objects of the type.
+
+                                 Syntax
+
+        abstract_interface_definition ::= ABSTRACT [LIMITED] INTERFACE
+
+        abstract_interface_list ::=
+            abstract_interface_subtype_mark
+            {AND abstract_interface_subtype_mark}
+
+                                 Legality Rules
+
+        An abstract interface type (also called an "interface type" or
+        "interface") is a specific abstract tagged type that is defined by
+an
+        abstract_interface_definition, or by a derived_type_definition or
+        formal_derived_type_definition where the keyword ABSTRACT
+        appears and the parent type is an interface type.
+
+        An interface type shall have no components.
+
+        All primitive operations of an interface type shall be abstract
+        subprograms or null procedures.
+
+        The type of a subtype named in an abstract_interface_list shall be
+an
+        interface type.
+
+        A descendant of a type which names an interface type in an
+        abstract_interface_list, or which is derived from an interface type,
+        is said to "implement" the interface and all of its ancestors.
+        A class-wide type implements the interfaces implemented by the
+        corresponding specific type. The corresponding full view of a
+        partial view of a type implements all interfaces implemented by
+        the partial view.
+
+        A type which implements an interface shall be limited if and only
+        if the interface type is limited.
+
+        If a partial view defines an interface type, then the corresponding
+        full view shall define an interface type.
+
+        If a full view implements an interface, then the corresponding
+        partial view (if any) shall implement the interface.
+
+        For an interface type declared in a visible part, a primitive
+        subprogram shall not be declared in the private part.
+
+        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.
+
+    --------
+
+    4.5.2
+
+    In paragraph 3, replace:
+
+        If the tested type is tagged, then the simple_expression shall
+resolve
+        to be of a type that covers or is covered by the tested type;
+
+    with
+
+        If the tested type is tagged, then the simple_expression shall
+resolve
+        to be of a type that covers or is covered by the tested type, or of
+a
+        class-wide type which covers an abstract interface type that is
+        implemented by the tested type.
+
+    --------
+
+    4.6
+
+    Add after paragraph 20:
+
+        If the target type is tagged and there exists no type that is an
+        ancestor of both the target type and the operand type, then either:
+
+            The target type shall cover or be an ancestor of an abstract
+            interface type which is implemented by the operand type; or
+
+            The operand type shall be a class-wide type that covers an
+abstract interface type which is
+            implemented by the target type.
+
+
+    In paragraph 21, replace "four" with "five".
+
+    --------
+
+    7.3
+
+    Replace
+        private_extension_declaration ::=
+          type defining_identifier [discriminant_part] is
+          [ABSTRACT] NEW ancestor_subtype_indication WITH PRIVATE;
+    with
+        private_extension_declaration ::=
+          type defining_identifier [discriminant_part] is
+          [ABSTRACT] NEW ancestor_subtype_indication
+          [[AND abstract_interface_list] WITH PRIVATE];
+
+    --------
+
+    8.3
+
+    Add after paragraph 12:
+
+        An implicit declaration of a subprogram which is neither abstract
+nor
+        a null procedure overrides that of a subprogram simultaneously
+        inherited by implementing an abstract interface.
+
+        If one subprogram overrides another and a type simultaneously
+inherits
+        subprograms corresponding to both, then the inherited subprogram
+        corresponding to the overriding subprogram overrides the other
+        inherited subprogram.
+
+        If an inherited subprogram corresponds to another subprogram and a
+        type simultaneously inherits subprograms corresponding to both, then
+        the subprogram corresponding to the inherited subprogram overrides
+the
+        other inherited subprogram.
+
+    Add after paragraph 23:
+
+        If two non-overridden homographs are simultaneously inherited as
+        primitive operations of a tagged type which implements an abstract
+        interface, then they shall be fully conformant and either both shall
+        be abstract subprograms or both shall be null procedures.
+
+    --------
+
+    12.5.1
+
+    Replace
+        formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
+                                           [WITH PRIVATE]
+    with
+        formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
+                                           [[AND abstract_interface_list]
+                                           WITH PRIVATE]
+
+
+    Add after paragraph 18:
+
+        If the formal type is an abstract interface type, then the actual
+type
+        shall be an abstract interface type.
+
+        The actual type shall implement any interfaces that are implemented
+by
+        the formal type.
+
+    --------
+
+    13.14
+
+    Add after paragraph 7:
+
+        The implementation of an abstract interface causes freezing of the
+        abstract interface type.
+
+    --------
+
+Discussion:
+
+   1) The "no components for interface types" rule does not conflict with
+the
+      "every tagged object has a tag" rule.
+      13.5.1(15) might be interpreted to mean that a tag is an
+      "implementation-defined component" of a tagged type, but apparently an
+      "implementation-defined component" is not a "component" (see, for
+      example, the definition of "needed components" for record aggregates).
+
+   2) An abstract interface type is an abstract tagged type; this point was
+      unclear in the AI.
+      The class-wide type associated with an interface type is not an
+      interface type.
+
+   3) It is intended that explicitly specifying that a type implements an
+      interface which it already implements should have no semantic effect.
+
+   4) A non-interface type may be derived from an interface type.
+
+   5) An abstract non-interface type cannot be directly derived from an
+      interface type. The syntax given in the AI for doing this
+      would violate the rule that an extension part is given as part of
+      a derivation if and only if the parent type is tagged.
+
+      I feel that preserving this rule is important. I don't want to take a
+      clean, simple rule which users encounter frequently and amend
+      it with an obscure exception.
+
+      If it is felt that direct derivation of an abstract non-interface type
+      from an an interface is an important capability that must be
+supported,
+      then alternative syntax should be considered. Even an interminable
+      string of keywords like
+
+          type T is abstract new Some_Interface_Type
+                    and not interface with null record;
+
+      would be preferable to the AI's proposal; perhaps the
+      "and not Interface" part could be omitted in the case where
+      a non-empty list of components is given.
+
+   6) It is intended that if two homographs are inherited as primitive
+      operations of a tagged type, then they can share one slot in the
+      dispatch table.
+
+   7) No formal abstract interface types. Use formal abstract tagged private
+      (or formal derived) instead. A type declared in the generic package
+spec
+      can't implement a formal tagged private, but that's ok. The situation
+      today with deriving a non-abstract type from a formal abstract
+      type is already quite ugly (the constract model does not include any
+way
+      to specify the set of abstract operations that must be overridden, so
+      that check is deferred until the instantiation) - we don't want to
+shine
+      a spotlight on this corner of the language.
+
+   8) The rule that only a tagged type may implement interfaces is not
+      stated explicitly; it is implicit in the syntax.
+
+   9) There are interactions between this AI and AI-279. In particular, it
+is
+      ok for Some_Abstract_Interface_Type'Class'Input to read in the tag of
+a
+      type which implements the interface but is not derived from it. The
+rule
+      given in AI-279 requires that Constraint_Error be raised in this case.
+      This check should be relaxed.
+
+   10) A primitive subprogram is inherited or it is not; it does not matter
+if
+       there is more than one reason for its inheritance - only one
+inherited
+       subprogram results.
+       Does this need to be stated explicitly?
+
+   11) The term "implement" is defined differently than in the AI. An
+interface
+       does not implicitly implement itself (because then it would inherit
+       operators from itself).
+
+   12) Nothing here (in particular, nothing in the 8.3 stuff) is intended to
+       change the semantics of a program which declares no interface types.
+
+   13) An example to illustrate some of the 8.3 stuff:
+
+           package P1 is
+               type T1 is abstract interface;
+               procedure P (X : T1) is abstract; -- P'1
+           end P1;
+
+           package P2 is
+               type T2 is abstract new P1.T1; -- P'2 (implicit)
+               procedure P (X : T2) is abstract; -- P'3
+           end P2;
+
+           type D is new Some_Tagged_Type and P1.T1 and P2.T2 with null
+record;
+
+       D inherits procedures P'4, P'5, and P'6, corresponding to
+       P'1, P'2, and P'3, respectively.
+
+       Since P'3 overides P'2, P'6 overrides P'5 by the "overriding is
+       preserved by inheritance" rule.
+
+       Since P'2 corresponds to P'1,  P'5 overrides P'4 by the "inherited
+       copies of your parent's ops hide inherited copies of your
+grandparent's
+       ops" rule.
+
+       The word "simultaneous" is used in contradistinction to the word
+       "previous" in 8.3(12). The word "corresponds" is used as
+       "corresponding" is used in 3.4(17).
+
+
+   14) Is this section of the proposed 8.3 addition,
+
+           If one subprogram overrides another and a type simultaneously
+           inherits subprograms corresponding to both, then the inherited
+           subprogram corresponding to the overriding subprogram overrides
+           the other inherited subprogram.
+
+       , necessary, or can it be derived from existing language rules?
+
+   15) Allowing implementation of a limited interface by a non-limited
+       type might be feasible, but it would introduce some complications:
+
+           A (dispatching) caller of a primitive function of a
+           limited interface type returning that type would not know
+           statically whether the (non-abstract) callee has a
+           return-by-reference result type. For replicated-generic
+           implementations, this would be something new.
+
+           The caller of such a function would need to
+           finalize the function result if and only if the function call
+           introduces an anonymous object (see 7.6.1(13/1))); this
+           would no longer be known statically.
+
+       Strictly from a user's perspective (i.e. ignoring any implementation
+       problems), would support for this construct even be desirable?
+
+       The problems associated with disallowing this construct in the
+       face of limited views of non-limited types (i.e. a limited
+       formal type where the corresponding actual type is non-limited)
+       are no worse than for 3.7(1)'s rule prohibiting access discriminants
+       for non-limited types.
+
+   16) Does the list of legality rules which need to be checked in
+       the private part of an instance (see 12.3(11), AARM 12.3(11.y)) need
+       to be extended? (The change to 3.9.1(3) is one such extension;
+       the last paragrah of 3.9.4 is another).
+
+   17) Recommended level of support for representation items for
+       interface types = "confirmation only" ? Or perhaps no
+       representation items at all for interface types - only
+       operational items; would this be a legality rule or just the
+       recommended level of support?
+
+   18) Should the AI include a sample implementation model for
+       My_Interface_Type'Class'Input ?
+
+   19) Are there interactions between interface types and
+       unknown discriminants that need to be addressed?
+       I don't see any.
+
+   20) Yes, it really is illegal if the parent type of a "with private"
+       type's completion happens to implement some interface that the
+       private view did not. This may turn out to be a pain.
+
+       Relaxing the rule that a partial view must implement all interfaces
+       implemented by the completion is not out of the question, but it
+could
+       open the door for some very peculiar situations. If this example,
+
+        package P is
+          packge Pkg is
+              type Ifc is abstract interface;
+              procedure Foo (X : Ifc) is abstract;
+          end;
+
+          type Parent_1 is tagged null record;
+
+          type T1 is new Parent_1 with private;
+        private
+          type Parent_2 is new Parent_1 and Pkg.Ifc with null record;
+          procedure Foo (X : Parent_2); -- Foo #1
+
+          type T1 is new Parent_2 with null record;
+        end;
+
+        with P;
+        package P_Client is
+          type T2 is new P.T1 and P.Pkg.Ifc with null record;
+          procedure Foo (X : T2); -- Foo #2
+          X : T2;
+        end P2_Client;
+
+        with P_Client;
+        package body P is
+          ...
+        begin
+          Pkg.Foo (Pkg.Ifc'Class (P_Client.X));
+             -- call Foo #2
+          Pkg.Foo (Pkg.Ifc'Class (T1 (P_Client.X)));
+             -- call Foo #1
+        end P2;
+
+      , were legal (it is illegal because the completion of T1 implements
+      an interface that is not implemented by the the partial view), then
+      we would have two dispatching calls to Pkg.Foo with the
+      two controlling operands having the same tag and yet different
+      bodies would be executed. The two conversions to Pkg.Ifc'Class
+      would map Pkg.Foo to different slots in the same dispatch table
+      because the source types of the conversions are different.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, May 16, 2002  11:31 PM
+
+> Unreserved keywords (see AI-284):
+
+Are you taking over this AI? It needs a discussion section at least.
+
+
+>     Throughout the RM:
+>         Replace "reserved word" with "keyword" (e.g. 3.9.3(2)).
+
+NO, NO, NO! At the meeting, Bob pointed out that there are 96 occurrences of
+this term in the standard. We can't make 94 text changes in the Amendment,
+people will reject it as being too large without even seeing what's new.
+Besides, it would take me at least 6 hours to do this, and I think I'd
+demand extra pay to compensate for the extreme boredom involved. (Each
+paragraph would have to be cut from the standard and properly formatted.)
+Plus the tools would need to be updated to handle many, many changes from a
+single AI.
+
+At the very least, you have to enumerate every place that needs to be
+changed. That would be necessary to help ensure that I don't miss any.
+
+The minutes say "Tucker suggests the age-old solution of defining "reserved
+word" to be equivalent to "reserved keyword". In the more general case, we
+simply say "keyword".
+
+I'm not adverse to making this change in paragraphs that we are changing
+anyway (there are already five such uses, four of which are new). But,
+please, lets stick with what we decided. We simply don't have the budget to
+spend on unnecessary massaging.
+
+...
+>     --------
+>
+>     3.9.3
+>
+>      Add after paragraph 6:
+>
+>          Corresponding rules apply for a type which inherits an abstract
+>          subprogram by implementing an abstract interface (see 3.9.4,
+3.4).
+
+Oh-oh! Do we have to define "corresponding" here? :-) :-)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, May 17, 2002   2:25 PM
+
+> Are you taking over this AI?
+
+No (or at least I didn't think that I was).
+
+I just wanted to provide enough context so that I
+could talk about the keyword INTERFACE in the
+AI-00251 writeup.
+
+> The minutes say "Tucker suggests the age-old solution of
+> defining "reserved word" to be equivalent to
+> "reserved keyword". In the more general case, we
+> simply say "keyword".
+
+Fine with me.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, May 17, 2002  10:52 AM
+
+Looks good.  I would suggest we define "implement" more generally,
+so that a derived type "implements" its parent type.  Then we can
+define "cover", etc. in terms of "implement" without any special cases.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, May 20, 2002   1:32 PM
+
+This sounds like a good approach.
+
+This could solve a problem with the initial proposal,
+where explicit conversion is required in cases where
+we probably want to allow implicit conversion.
+
+Given this example
+
+    type Ifc is abstract interface;
+    type T is new Some_Tagged_Type and Ifc with null record;
+
+    type Ifc_Ref is access all Ifc'Class;
+
+    X : aliased T;
+    Ptr1 : Ifc_Ref := Ifc'Class (X)'Access; -- legal
+    Ptr2 : Ifc_Ref := X'Access; -- legal ?
+
+, I believe that the initial proposal would  allow the
+first use of the Access attribute, but not the second.
+
+I think that we want to allow the second use.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 20, 2002  1:40 PM
+
+Yes, I agree that Ifc'Class should "cover" T and its derivatives.
+
+I believe that the current AI implies that, but that your
+proposed wording does not.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, June 5, 2002   3:49 PM
+
+Tuck says:
+> I would suggest we define "implement" more generally,
+> so that a derived type "implements" its parent type.  Then we can
+> define "cover", etc. in terms of "implement" without any special cases.
+
+I agree that if type T implements some interface type Ifc, then we want to
+define "cover" so that Ifc'Class covers T.
+
+I'm not so sure about changing the definition of "implement".
+
+It would be nice to use a generalized form of "implementation" for
+determining operator inheritance - a type inherits operators from the types
+that it implements, and from no others.
+
+This rule would imply that a derived type inherits operators not only from
+its parent, but from all of its parent's ancestors.
+
+Typically this extra inheritance would make no difference (all the extra
+inherited operators would be overridden), but this would be an incompatible
+change if an ancestor has primitive subprograms that the parent lacks (this
+can only happen in the untagged case):
+
+    package Pkg is
+      type T1 is null record;
+      type T2 is new T1;
+      procedure P (X : T1);
+      type T3 is new T2; -- T3 should not inherit a P procedure
+    end Pkg;
+
+With that in mind, here is a revision of my previous attempt at wording
+for AI-251.
+
+  -- Steve
+
+----------------------------------------------------------------
+----------------------------------------------------------------
+
+    3.4.1(9)
+
+    Add after the first sentence:
+      If a type T1 implements an abstract interface type T2 (see 3.9.4),
+      then T2'Class also covers all types covered by T1'Class.
+
+    --------
+
+    4.5.2: Ignore the changes I proposed earlier; revert to the current RM
+text.
+
+    --------
+
+    4.6:
+
+    Ignore the changes I proposed earlier.
+
+    Replace paragraphs 21-23 with:
+
+      If the target type is tagged, then either:
+
+        The operand type shall be covered by or descended from the target type; or
+
+        The operand type shall be a class-wide type that covers the target type.
+
+      If the target type is not included in any of the above five cases,
+      there shall be a type that is an ancestor of both the target type and the
+      operand type.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent