CVS difference for ais/ai-00335.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00335.txt

--- ais/ai-00335.txt	2003/10/29 22:54:13	1.3
+++ ais/ai-00335.txt	2004/04/06 21:57:15	1.4
@@ -1,17 +1,20 @@
-!standard 13.13.02     (04)                            03-07-30  AI95-00335/00
+!standard 03.02.03     (06)                            04-04-02  AI95-00335/01
 !class binding interpretation 03-07-30
 !status received 03-04-23
 !qualifier Omission
 !priority Low
 !difficulty Medium
-!subject Stream attributes are [never] dispatching
+!subject Stream attributes may be dispatching subprograms
+A stream-oriented attribute of a specific tagged type T is a dispatching
+subprogram in the circumstances where it is possible to ensure that this
+attribute is available for all descendants of T.
-Are stream attributes of tagged types dispatching?
+Are stream attributes of tagged types dispatching? (You bet!)
 The stream attributes as applied to tagged types do not appear to be
 treated as dispatching operations, since they don't fall into the
@@ -19,22 +22,88 @@
 However, the semantics of 'Class'Output is defined to make a dispatching
 call to 'Output. Shouldn't a user-defined 'Class'Output be able to make the
-same call?
+same call? (Yes.)
+(See wording.)
+Add after 3.2.3(6):
-[I didn't write up this AI, as it is not clear whether these should (or should
-not) be dispatching. Note that parts of 'Class'Input is magic, so it probably
-doesn't matter if more if it is magic.]
+For a specific type, the stream-oriented attributes of the type that are
+available at the end of the list of declarative_items where the type is
+AARM Note: For a type declared immediately within a package_specification which
+has a partial view, the list of declarative_items to consider is the visible
+part of the package.
+Even if a stream-oriented attribute is specified by an
+attribute_definition_clause, it is not itself considered a user-defined
+subprogram, so it is not inherited.  Rather, the rules explaining what happens
+to the stream-oriented attributes on type derivation are spelled out in chapter
---!corrigendum 13.13.02(0x)
+It seems reasonable for a user to want to make a dispatching call to one of the
+stream-oriented attributes of type T, especially in the body of a user-defined
+stream-oriented attribute of T'Class. After all, the predefined T'Class does
+such a dispatching call, and we want to limit the amount of magic that is going
+on in these predefined attributes (we know that we cannot entirely eliminate
+that magic).
+The best solution seems to decide that stream-oriented attributes of specific
+types are primitive subprograms of the type. This makes them dispatching
+subprograms in the case of tagged types. Note however that they aren't
+inheritable in the sense of 3.4(17). They behave more like predefined
+operators, and are created anew for each type, based on the properties of the
+We must be cautious, though, for two reasons:
+1 - If T is limited, (some of) its stream-oriented attributes may not be
+2 - Because we are going to do a dispatching call, we must ensure that the
+attribute is available for T and all of its descendants.
+This is a situation quite similar to the one considered in item #3 of AI-195,
+where we were trying to determine under which circumstances a stream-oriented
+attribute of T'Class is available, given that such an attribute makes a
+dispatching call to the corresponding attribute of T. So we can essentially
+borrow the words of AI-195.
+Note that, because the attribute_definition_clauses for T always occur before T
+is frozen, implementations should have no problem adding the appropriate
+stream-oriented attributes to the dispatch tables, just like they add vanilla
+dispatching subprograms.
+There is a small bug in AI-195: the discussion of item #5 has the parenthetical
+comment: "(stream-oriented attributes are always called in a non-dispatching
+manner)".  This comment was never true (precisely because the predefined
+attributes of T'Class make a dispatching call to the corresponding attribute of
+T) but it is even falser now.  It should read "(stream-oriented attributes are
+sometimes called in a non-dispatching manner)".
+<<Integration Issue: If this AI is adopted, some of the replacement wording for
+13.13.2(26/1) in AI-195 should be changed to read "the corresponding attribute
+of T is a primitive subprogram of T".  This would avoid a bit of wording
+!corrigendum 3.2.3(6)
+@xbullet<For a specific type declared immediately within a
+package_specification, any subprograms (in addition to the enumeration
+literals) that are explicitly declared immediately within the same
+package_specification and that operate on the type;>
+@xbullet<For a specific type, the stream-oriented attributes of the type that
+are available at the end of the list of declarative_items where the type is
 !ACATS test

Questions? Ask the ACAA Technical Agent