CVS difference for ai05s/ai05-0113-1.txt

--- ai05s/ai05-0113-1.txt	2009/12/08 18:48:08	1.3
+++ ai05s/ai05-0113-1.txt	2009/12/29 06:42:28	1.4
@@ -1,5 +1,4 @@
-!standard 3.9(12.1/2)                                         09-12-08  AI05-0113-1/03
-!standard 3.9(25.3/2)
+!standard 3.9(12.1/2)                                         09-12-28  AI05-0113-1/04
 !standard 3.9(26.1/2)
 !standard 13.3(76)
 !class binding interpretation 08-10-06
@@ -13,7 +12,7 @@
 !summary
 
 If a user-specified external tag S'External_Tag is the same as T'External_Tag for some
-other type, execution of the partition is erroneous.
+other declaration, Program_Error is raised by the elaboration of S.
 
 The Implementation Advice for Internal_Tag suggests returning a tag for a type that
 belongs to some master of the call to Internal_Tag.
@@ -36,32 +35,36 @@
 
 !wording
 
-Add before 3.9(25.3/2):
 
-Bounded (run-time) Errors
+AARM Note: Rules for specifying external tags will usually prevent an external tag
+from identifying more than one type. However, this can happen if a tagged type
+is declared with a specified tag within a subprogram that is called by multiple tasks,
+or if a generic body contains a declaration of a tagged type and there are multiple
+instances. (There is an exception to the general requirement that default external tags
+be unique for this case.)
+
+
+Modify 3.9(12.1/2):
+
+The function Descendant_Tag returns the (internal) tag for the type that corresponds
+to the given external tag and is both a descendant of the type identified by the Ancestor
+tag and has the same accessibility level as the identified ancestor. Tag_Error is raised
+if External is not the external tag for such a type. Tag_Error is also raised if the
+specific type identified is a library-level type whose tag has not yet been created{, or
+if the given external tag identifies more than one type that has the appropriate Ancestor
+and accessibility level}.
+
+AARM Note: Rules for specifying external tags will usually prevent an external tag
+from identifying more than one type. However, this can happen if a generic body
+contains a derivation of a tagged type declared outside of the generic, and there
+are multiple instances at the same accessibility level as the type. (There is an
+exception to the general requirement that default external tags be unique for this case.)
+
+[Editor's note: I changed the exception for multiple type to Tag_Error as it is more
+consistent and will require fewer special mechanisms that way. OTOH, Program_Error
+would identify this particular problem more clearly. Also note that Internal_Tag
+was already defined to return "a tag", so we don't need any rule for that case.]
 
-It is a bounded error if the value of External passed to Tags.Internal_Tag or
-Tags.Descendant_Tag identifies more than one tagged type with the appropriate ancestor
-and accessibility level. Either Program_Error is raised, or one of the identified
-tagged types is returned.
-
-AARM Note: This can happen if a generic body contains a derivation of a tagged type
-declared outside of the generic, and there are multiple instances at the same
-accessibility level. (There is an exception to the general requirement that default
-external tags be unique for this case.)
-
-If Program_Error is not raised, and the returned tag is used by 'Input to read a
-stream, execution can become erroneous (the value may be read with the wrong type).
-
-[Editor's note: I don't exactly know what we should say about this case, but it
-seems wrong to remain silent. This is a real problem as a container instance
-instantiated in a generic body would not be required to have a unique external tag --
-see 13.3(76). The other option is to delete the "except" wording from 13.3(76),
-perhaps that is a better idea (although it could be an implementation hardship
-for certain Ada compilers starting with 'J'. Be we could use the same scheme we use
-for generic body exceptions (we hash the name with the location of the instance parameter
-block, which makes it unique, but not readable).]
-
 Modify 3.9(26.1/2) as follows:
 
 Internal_Tag should return the tag of a type{, if one exists,} whose innermost
@@ -76,23 +79,33 @@
 Dynamic Semantics
 
 If a user-specified external tag S'External_Tag is the same as T'External_Tag for
-some other tagged type declared in the partition, Program_Error is raised by the
-elaboration of the attribute_definition_clause.
+some other tagged type declared by a different declaration in the partition,
+Program_Error is raised by the elaboration of the attribute_definition_clause.
 
 AARM Ramification
 This rule does not depend on the visibility of the other tagged type, but it does
-depend on the existence of the other tagged type.
-The other tagged type could have the default external tag or a user-specified
-external tag. Note that this means that a tagged type declared in a generic
-body that has user-defined external tag can only be instantiated once without
-raising Program_Error.
+depend on the existence of the other tagged type. The other tagged type could have
+the default external tag or a user-specified external tag.
+
+This rule allows the same declaration to be elaborated multiple times. In that case,
+different types could have the same external tag. If that happens, Internal_Tag would
+return some unspecified tag, and Decendant_Tag probably would return the intended
+tag (using the given ancestor to determine which type is intended). However, in some
+cases (such as multiple instantiations of a derived tagged type declared in a generic
+body), Tag_Error might be raised by Descendant_Tag if multiple types are identified.
+
+Note that while there is a race condition inherent in this definition (which
+attribute_definition_clause raises Program_Error depends on the order of elaboration),
+it doesn't matter as a program with two such clauses is simply wrong. Two types
+that both come from the same declaration are allowed, as noted previously.
 
 Add after 13.3(76):
 
 Implementation Permissions
 
 If a user-specified external tag S'External_Tag is the same as T'External_Tag for
-some other tagged type declared in the partition, the partition may be rejected.
+some other tagged type declared by a different declaration in the partition, the
+partition may be rejected.
 
 AARM Ramification:
 This is, in general, a post-compilation check. This permission is intended for
@@ -103,28 +116,24 @@
 very rare that there would be a problem.
 
 !discussion
-
-We make the specification of the tag erroneous so that an implementation can
-raise an exception should it be able to detect the problem.
 
-Requiring a runtime check would require some sort of runtime table to check
-External_Tag names; the table would need exclusion in case multiple tasks are
-creating tagged types at the same time. That seems ike unnecessary overhead
-for a very unlikely case.
+The runtime check will require some sort of runtime table to check
+External_Tag names; the table will need exclusion in case multiple tasks are
+creating tagged types at the same time. The mechanism used to implement
+Internal_Tag should be sufficient.
 
 A post-compilation check is not possible in general, as tagged types can
 be created in subprograms and tasks, and it is possible that the two types
-with conflicting external tags never exist at the same time. Such a program
-is *not* erroneous. [Or do we want to go further and ban this, too?? Seems
-like a slippery slope... - ED]
+with conflicting external tags never exist at the same time. We do allow
+compilers to reject programs that probably will fail this check at runtime.
 
 Note that for default external tags, the implementation needs to prevent
 conflicts from happening (as noted in 13.3(76)). However, generic instance
 bodies are excepted from this requirement, and thus we need to worry about
-that case, as well. Internal_Tag is already covered, as it is defined to
+that case, as well. Internal_Tag does not need a rule, as it is defined to
 return "*a* tag" (that was intended to cover recursion, but it works here,
-too). So we just need a rule for Dependent_Tag. We made it a Bounded Error
-to minimize disruption but still to allow detection.
+too).  But we do need a rule for Dependent_Tag. We made it raise Tag_Error
+in that case to use the same exception as does other problems.
 
 For (2), we change the wording to "a master". The original intent was that
 master of the innermost task was "the" master, but that seems wrong (it would