CVS difference for ais/ai-00216.txt

Differences between 1.16 and version 1.17
Log of other versions for file ais/ai-00216.txt

--- ais/ai-00216.txt	2003/10/29 22:54:08	1.16
+++ ais/ai-00216.txt	2004/11/02 01:50:19	1.17
@@ -1,4 +1,4 @@
-!standard B.03.03      (00)                         03-06-06  AI95-00216/13
+!standard B.03.03      (00)                         04-10-25  AI95-00216/14
 !standard B.03         (60.2)
 !class amendment 99-03-23
 !status Amendment 200Y 03-02-17
@@ -101,7 +101,7 @@
 If an unchecked union completes a private type or private extension, the
 partial view must not have known discriminants or it must be an unchecked
 union. For contract model reasons, in an instantiation of a generic, if the
-actual type is an unchecked union, the formal type must not have known
+actual type is an unchecked union, the formal type must not have with known
 discriminants, or it must be an unchecked union.
 
 
@@ -171,10 +171,14 @@
 known_discriminant_part shall not be an unchecked union type.
 
 An unchecked union subtype shall only be passed as a generic actual
-parameter if the corresponding formal type does not have
-a known_discriminant_part, or is a formal derived type that is an
-unchecked union type.
+parameter if the corresponding formal type has no known discriminants
+or is an unchecked union type.
 
+AARM Note: This includes formal private types without a known_discriminant_part,
+formal derived types that do not inherit any discriminants (Formal
+derived types do not have known_discriminant_parts), and formal derived types
+that are unchecked union types.
+
                 Static Semantics
 
 An unchecked union type is eligible for convention C.
@@ -369,15 +373,11 @@
 The completion of an incomplete or private type declaration having a
 @fa<known_discriminant_part> shall not be an unchecked union type.
 
-An unchecked union subtype shall not be passed as a generic actual parameter
-if the corresponding formal type has a @fa<known_discriminant_part> or
-is a formal derived type that is not an unchecked union type.
-
 An unchecked union subtype shall only be passed as a generic actual
-parameter if the corresponding formal type does not have
-a @fa<known_discriminant_part>, or is a formal derived type that is an
-unchecked union type.
+parameter if the corresponding formal type has no known discriminants
+or is an unchecked union type.
 
+
 @i<@s8<Static Semantics>>
 
 An unchecked union type is eligible for convention C.
@@ -2880,6 +2880,326 @@
 Standard. So, you are completely correct when you say:
 
 >  but that is outside of the scope of this AI.
+
+*************************************************************
+
+!topic Nitpick regarding Unchecked_Union proposal
+!reference AI95-00216
+!from Adam Beneschan 04-10-25
+!discussion
+
+
+I think there's a mistake in the text of this AI.  The !wording
+section says:
+
+    An unchecked union subtype shall only be passed as a generic
+    actual parameter if the corresponding formal type does not have a
+    known_discriminant_part, or is a formal derived type that is an
+    unchecked union type.
+
+
+The !corrigendum contains both these paragraphs:
+
+    An unchecked union subtype shall not be passed as a generic actual
+    parameter if the corresponding formal type has a
+    @fa<known_discriminant_part> or is a formal derived type that is
+    not an unchecked union type.
+
+    An unchecked union subtype shall only be passed as a generic
+    actual parameter if the corresponding formal type does not have a
+    @fa<known_discriminant_part>, or is a formal derived type that is
+    an unchecked union type.
+
+
+It appears that the intent was to include only one of the paragraphs
+shown in the !corrigendum section, but the other one got accidentally
+left in.  My guess is that the first paragraph of the !corrigendum is
+correct, and both the second paragraph there and the paragraph in the
+!wording section are wrong.  The last clause of
+
+    An unchecked union subtype shall only be passed as a generic
+    actual parameter if the corresponding formal type does not have a
+    known_discriminant_part, or is a formal derived type that is an
+                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+    unchecked union type.
+    ^^^^^^^^^^^^^^^^^^^^
+
+doesn't really make sense as written, since a formal derived type
+can't have a known_discriminant_part (RM95 12.5.1(11)).  But that's
+just my guess---I really don't know what was intended.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 25, 2004 at  9:27 PM
+
+> It appears that the intent was to include only one of the paragraphs
+> shown in the !corrigendum section, but the other one got accidentally
+> left in.  My guess is that the first paragraph of the !corrigendum is
+> correct, and both the second paragraph there and the paragraph in the
+> !wording section are wrong.
+
+That's unlikely. It's much more likely that the first paragraph of the
+!corrigendum is left over. The only difference is that it is a double
+negative; the rewritten paragraph doesn't have the double negative and thus
+is easier to read.
+
+>  The last clause of
+>
+>     An unchecked union subtype shall only be passed as a generic
+>     actual parameter if the corresponding formal type does not have a
+>     known_discriminant_part, or is a formal derived type that is an
+>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>     unchecked union type.
+>     ^^^^^^^^^^^^^^^^^^^^
+>
+> doesn't really make sense as written, since a formal derived type
+> can't have a known_discriminant_part (RM95 12.5.1(11)).  But that's
+> just my guess---I really don't know what was intended.
+
+Formal private types can have known_discriminant_parts. The phrase doesn't
+say anything about derived types - it applies to all kinds of formals that
+might be matched by an unchecked union.
+
+*************************************************************
+
+From: Adam Beneschan
+Sent: Monday, October 25, 2004 at  9:39 PM
+
+My point is that since formal *derived* types cannot have known
+discriminant parts, the clause that I've marked (starting with "or")
+is logically redundant, since it cannot possibly apply to anything,
+the way this paragraph is written.  That's why I suspected this was
+not the intended wording.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 25, 2004 at  9:27 PM
+
+I'd started drafting a correction when this came in.
+
+I've researched the history of this wording, and as I had suspected, it
+happened at the last minute in editorial review. The wording was changed to
+accurately reflect the intent was specified in in the !proposal. The problem,
+as you note, is that all derived types don't have known_discriminant_parts --
+the (written) intent is and always has been wrong.
+
+My guess is that we have to discuss private types and derived types separately,
+because derived types inherit the discriminants without explicitly mentioning
+them. And we're trying to disallow anything with discriminants that can be
+manipulated without the type being an unchecked union type.
+
+I think that the correct wording is:
+
+  An unchecked union subtype shall only be passed as a generic actual
+  parameter if the corresponding formal type is a formal private type that
+  does not have a known_discriminant_part, or is a formal derived type that
+  is an unchecked union type.
+
+(I don't think that an unchecked_union type could match any other kind of
+formal type, so this is a complete list. It would be OK for a formal derived
+type with no discriminants to match an unchecked union type, but I think that
+could only happen for a tagged type, and that hardly seems worth allowing,
+especially with the complicated wording needed.)
+
+Humm, the original replacement wording that Pascal had proposed was:
+
+  A unchecked union subtype shall only be passed as a generic actual
+  parameter if the corresponding formal type has no known discriminants, or is
+  a formal derived type that is an unchecked union type.
+
+which is actually correct (as a derived type inherits known discriminants from
+its ancestor). He didn't catch it when I completely misunderstood what was
+going on.
+
+(From rereading the mail many times, I think I've proved that I'm the only one
+who is confused here; but I managed to screw it up big time!!)
+
+I'm not sure why the rule mentions "formal derived type" in the second part;
+the only kind of generic formal that is defined to be an unchecked union type
+is a formal derived type; a private type is never an unchecked union (that's in
+the preceding paragraph of the wording).
+
+So I think we can just use:
+
+  A unchecked union subtype shall only be passed as a generic actual
+  parameter if the corresponding formal type has no known discriminants or is
+  an unchecked union type.
+
+Along with an AARM Note.
+
+I'll update the AI with this, and we'll consider it as a AI correction at the
+next ARG meeting.
+
+*************************************************************
+
+!topic Unchecked_Union (AI-216) and discriminant checks
+!reference AI95-00216, RM95 4.6(43,45), RM95 11.5
+!from Adam Beneschan 04-10-25
+!discussion
+
+The proposed text for AI-216 says, "Discriminant_Check is suppressed
+for an unchecked union type".  However, there are a couple cases where
+it's not clear what this means.  The Discrminant_Check entry in the
+index refers to 4.6(43) and 4.6(45), in the section on type
+conversions; both of these paragraphs refer to two types, the target
+type and the operand type.  So it isn't clear in those cases which of
+those two types the Discriminant_Check is being performed on, and thus
+which one would be suppressed.
+
+Specifically:  Given these declarations:
+
+procedure Proc (N1, N2 : Integer) is
+
+   type T1 (X : Integer) is record ... end record; -- with variant part
+   subtype S1 is T1 (N1);
+
+   type T2 is new T1;
+   pragma Unchecked_Union (T2);
+   subtype S2 is T2 (N2);
+
+   V1 : S1;
+   V2 : S2;
+
+Assuming N1 /= N2, which, if either, of these assignments will have
+Discriminant_Check suppressed; and which, if either, will cause
+Constraint_Error to be raised?
+
+   V1 := S1 (V2);
+
+   V2 := S2 (V1);
+
+I believe the AI is ambiguous here, and it might be nice if it were
+clearer on this.  (The RM section on pragma Suppress doesn't help; it
+might be nice if that section were clearer too, in the case where just
+one of the involved types is specified in the On parameter of a
+Suppress pragma.)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 25, 2004 at  11:06 PM
+
+Adam Beneschan wrote:
+
+> The proposed text for AI-216 says, "Discriminant_Check is suppressed
+> for an unchecked union type".  However, there are a couple cases where
+> it's not clear what this means.  The Discrminant_Check entry in the
+> index refers to 4.6(43) and 4.6(45), in the section on type
+> conversions; both of these paragraphs refer to two types, the target
+> type and the operand type.  So it isn't clear in those cases which of
+> those two types the Discriminant_Check is being performed on, and thus
+> which one would be suppressed.
+
+That's certainly true, but it is worse than you think.
+
+I don't think anyone considered conversions between different *types*; all
+of the talk was between *subtypes*. So I don't think that there is any idea
+at all what should happen in such a case. (Note that such a case can't
+really happen in practice, because you can only give the pragma if there is
+no primitive operations on the type, its not by-reference, and its
+untagged.)
+
+...
+> I believe the AI is ambiguous here, and it might be nice if it were
+> clearer on this.  (The RM section on pragma Suppress doesn't help; it
+> might be nice if that section were clearer too, in the case where just
+> one of the involved types is specified in the On parameter of a
+> Suppress pragma.)
+
+We discovered during the definition of pragma Unsuppress that there is no
+agreement between vendors what the On parameter means. Any attempt to define
+it would cause major incompatibilities for someone (probably everyone), and
+we decided to just put the entire On parameter in Obsolescent features.
+
+The intent is that we would not say what happened in cases where more than
+one entity was involved and the checking was different. Now, you point out
+that the definition of Unchecked_Union is depending on precisely that.
+
+I don't have a clue as to how to fix this. Trying to define precisely what
+checks are suppressed by a particular type is a can of worms the size of a
+watertower - we'll never finish the amendment if we try. And it makes no
+sense at all to define it in this only specific case.
+
+I'd prefer to get "suppress" out of this AI, as it has nothing to do with
+suppressing checks; there shouldn't be any checks in the first place (the
+discriminant values aren't known). But that's a lot of work.
+
+Or we could simply disallow having the pragma on derived types (that isn't
+useful, I don't think).
+
+Another choice is to decide to not answer your question, which also seems
+bad.
+
+A final choice is to just drop the stupid AI, it's not worth the hassle.
+
+In any event, we'll have to reopen the AI to decide.
+
+           Randy.
+
+P.S. I certainly wish you would have sent this one first; I wouldn't have
+wasted 90 minutes fixing the first (easy) problem had I known about this
+one.
+
+*************************************************************
+
+From: Adam Beneschan
+Sent: Tuesday, October 26, 2004 at  10:34 AM
+
+> P.S. I certainly wish you would have sent this one first; I wouldn't have
+> wasted 90 minutes fixing the first (easy) problem had I known about this
+> one.
+
+Sorry about that.  As you may have guessed, I'm now working on
+implementing this AI, and I sent the problems I noticed as soon as I
+noticed them.  FYI, I'm still working on the implementation and
+there's a chance I may notice other issues.  If it would help, if I do
+any work on any other AI's before the 0Y standard is finalized, I'll
+try to send things all at once instead of piecemeal.
+
+*************************************************************
+
+From: Adam Beneschan
+Sent: Tuesday, October 26, 2004 at  10:55 AM
+
+I wrote:
+
+> procedure Proc (N1, N2 : Integer) is
+>
+>    type T1 (X : Integer) is record ... end record; -- with variant part
+>    subtype S1 is T1 (N1);
+>
+>    type T2 is new T1;
+>    pragma Unchecked_Union (T2);
+>    subtype S2 is T2 (N2);
+>
+>    V1 : S1;
+>    V2 : S2;
+>
+> Assuming N1 /= N2, which, if either, of these assignments will have
+> Discriminant_Check suppressed; and which, if either, will cause
+> Constraint_Error to be raised?
+>
+>    V1 := S1 (V2);
+>
+>    V2 := S2 (V1);
+
+On second reading, it appears that these questions are at least
+partially answered by the !proposal section (the paragraph beginning
+"The pragma Unchecked_Union may be applied to a derived type...).  It
+would appear that the first conversion is erroneous but does not raise
+Constraint_Error (although the !proposal doesn't say specifically what
+happens when the operand subtype is constrained; that case probably
+wouldn't happen in real code, though).  The second would raise
+Constraint_Error.  This paragraph also explains why it was considered
+useful to apply the pragma to derived types.
+
+My apologies for missing this paragraph the first time.
+
+However, the language in the !wording and !corrigendum, which simply
+says "Discriminant_Check is suppressed for the type", doesn't really
+reflect the intent expressed by the !proposal paragraph.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent