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

--- ai05s/ai05-0113-1.txt	2008/10/25 04:53:14	1.2
+++ ai05s/ai05-0113-1.txt	2009/12/08 18:48:08	1.3
@@ -1,4 +1,4 @@
-!standard 3.9(12.1/2)                                         08-10-06  AI05-0113-1/02
+!standard 3.9(12.1/2)                                         09-12-08  AI05-0113-1/03
 !standard 3.9(25.3/2)
 !standard 3.9(26.1/2)
 !standard 13.3(76)
@@ -16,7 +16,7 @@
 other type, execution of the partition is erroneous.
 
 The Implementation Advice for Internal_Tag suggests returning a tag for a type that
-beongs to some master of the call to Internal_Tag.
+belongs to some master of the call to Internal_Tag.
 
 !question
 
@@ -24,7 +24,7 @@
 for two different type declarations may be the same, probably by accident. What is
 returned from Tags.Internal_Tag and Tags.Descendant_Tag in that case?
 
-(2) 3.9(26/2) says that Tag_Error can be raised if there no type whose innermost
+(2) 3.9(26/2) says that Tag_Error can be raised if there are no types whose innermost
 master is a master of the point of the function call, but 3.9.(26.1/2) suggests that
 Internal_Tag return a tag of a type whose tag is *the* innermost master of the point
 of the call. But the innermost master is usually the function call itself, which
@@ -40,23 +40,32 @@
 
 Bounded (run-time) Errors
 
-It is a bounded error if the value of External passed to Tags.External_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 in two cases:
-* If a specified external tag matches that of some other type in the partition.
-This is already erroneous (see 13.3).
-* 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.) This second case is the one that this rule is
-intended to catch.
+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 whose innermost master is {a}[the]
-master of the point of the function call{, if one exists}.
+Internal_Tag should return the tag of a type{, if one exists,} whose innermost
+master is {a}[the] master of the point of the function call.
 
 AARM Note: There is no Advice for the result of Internal_Tag if no such type exists.
 In most cases, the Implementation Permission can be used to raise Tag_Error, but
@@ -64,15 +73,34 @@
 
 Add before 13.3(76):
 
-Erroneous Execution
+Dynamic Semantics
 
-If a non-confirming user-specified external tag S'External_Tag is the same as
-T'External_Tag for some other tagged type, execution of the partition is erroneous.
-
-AARM Note
-An implementation can raise an exception such as Program_Error if this can be detected.
-Otherwise, it is likely that Tags.Internal_Tag and Tags.Descendant_Tag will return
-an unspecified tag.
+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.
+
+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.
+
+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.
+
+AARM Ramification:
+This is, in general, a post-compilation check. This permission is intended for
+implementations that do link-time construction of the external tag lookup table;
+implementations that dynamically construct the table will likely prefer to
+raise Program_Error upon elaboration of the problem construct.
+We don't want this check to cause any implementation complexity, as it will be
+very rare that there would be a problem.
 
 !discussion