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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0123-1.txt

--- ai05s/ai05-0123-1.txt	2008/12/05 04:55:35	1.3
+++ ai05s/ai05-0123-1.txt	2008/12/05 05:27:44	1.4
@@ -1,4 +1,4 @@
-!standard  4.5.2(10-26)                                        08-11-17    AI05-0123-1/02
+!standard  4.5.2(10-26)                                        08-11-17    AI05-0123-1/03
 !class Amendment 08-10-17
 !status work item 08-10-17
 !status received 08-09-03
@@ -66,9 +66,39 @@
 compile-time error, or always get the same semantics as Ada 2005
 for a direct call on "=" '.
 
-With this in mind, the preceding corner cases are all
-defined to be statically illegal.
+This suggests that the preceding corner cases might all defined
+to be illegal. That, however, is viewed as being too draconian.
 
+These cases are dealt with as follows:
+
+   1) The "composed" equality operator for a type with a component
+      whose primitive "=" operator is abstract is also abstract.
+      In the case of a nonabstract tagged type, this operator would
+      have to be overridden just like any other abstract operation
+      (ditto in the case of a nonabstract extension of a parent type
+      which has an abstract "=" operator).
+      A type with an abstract "=" operator cannot be passed as
+      a generic actual corresponding to a formal private or formal
+      derived type (except in the case of a formal derived type which
+      also has an abstract "=" operator).
+   2) A user-defined primitive "=" operator for an untagged record
+      type may not be declared after the freezing point of the type,
+      nor may it be declared in the private part of a package
+      spec if (a full or partial view of) the record type is declared
+      in the visible part.
+   3) The case of an untagged record type with a user-defined primitive
+      "=" op where the predefined "=" op is referenced before it is
+      overridden is illegal except in the case of a rename of the
+      not-yet-overridden op. Such a rename has "squirreling"
+      semantics (see AARM 8.5.4(8.g))
+
+[Even if #2 and #3 get the usual boilerplate about rechecking in an
+expanded spec, there is still a question about violations within
+an expanded body. What are the dynamic semantics of a call to an
+overrider-pending "=" operator of a type derived from a formal private
+untagged type where the actual turns out to be a record type (tagged or
+untagged)? Or do we assume the worst and reject the generic body?]
+
 In the case of a generic formal private type where the corresponding
 actual parameter is an untagged record type with a user-defined
 primitive "=" op, reemergence does not take place. A call to the
@@ -1405,79 +1435,196 @@
 
 ****************************************************************
 
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+From: Randy Brukardt
+Sent: Monday, November 17, 2008  4:55 PM
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+You have the following as statically illegal:
+>    1) An untagged record type with a user-defined abstract
+>       primitive "=" op.
+>    2) An untagged record type declared in the visible part of a package
+>       with a user-defined primitive "=" op declared in the private
+>       part or the body of the package.
+>    3) An untagged record type with a user-defined primitive "=" op
+>       where the predefined "=" op is referenced before it is
+>       overridden.
+
+It's not clear to me what you mean by this, at least in the first case.
+
+I originally thought that you meant that calling "=" for such an equality would
+be illegal. That would be what the programmer intended, but I don't see how to do
+that without nasty generic contract problems.
+
+OTOH, if you mean that declaring an abstract "=" is illegal, that seems like a
+significant incompatibility. For one thing, that would render ASIS '99 illegal
+(and leave us stuck again with the problem of how to change that for the new ASIS,
+one that we could not usefully decide any improvement to the last time we looked
+at it). It also means that anyone who tried to undefine "=" as ASIS did would be
+broken (and left with no workaround other than redefining "=" to raise an
+exception -- going from compile-time to run-time detection of errors is not going
+in the right direction). So this doesn't seem like a good idea, either.
+
+My understanding is that Tucker suggested that abstract equality would essentially
+work as it does now (the predefined "=" would re-emerge in cases where a direct
+illegality of the call is impossible), since it isn't reasonable to make all such
+cases statically illegal. (Your quote of him says as much.) You seem to be trying
+to make all such cases illegal, reasonable or not.
+
+The best idea I can think of would be that if a component that has a record type
+has abstract equality, then the composed equality is also abstract.
+(This case can't happen currently for a non-abstract tagged type, because abstract
+operations are only allowed on abstract tagged types. In the abstract case, the
+result would be the same.) That would make direct calls to "=" illegal in that
+case. Generics, however, would still re-emerge.
 
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+From: Tucker Taft
+Sent: Monday, November 17, 2008  4:54 PM
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+I would agree with all but the case of an abstract primitive "=".
+That seems to be a useful way to say that although copying is well defined, there
+isn't a single "=" that always makes sense.
+
+To preserve "the principle", the "composed" equality for a type with such a type
+as a subcomponent would also be abstract. Any type with an abstract composable "="
+could not be passed as an actual to a non-limited formal private or derived type
+(unless the ancestor type of the formal derived type similarly has an abstract "=").
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+That's pretty draconian, but not as draconian as making the abstract "=" illegal
+from the get-go.
 
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+From: Randy Brukardt
+Sent: Monday, November 17, 2008  5:02 PM
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+As soon as I pressed "send" on my reply to Steve, I thought of a Baird-like problem
+with this. (Since this is Steve's AI, someone else will have to take his role of
+blowing up all of the good ideas!)
+
+This solution (proposed by both you and me without knowledge of the other) doesn't
+work for a concrete tagged type that has an extension component that has an
+abstract "=" operation. (Such a component would have to be untagged.) In that case,
+this rule would make the "=" abstract, but that would violate the principle that
+no concrete tagged type has an abstract operation. And that principle is very
+important if dispatching is allowed.
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+One could make an exception and have "=" re-emerge in that case, but once you do
+that, why bother with any of it??
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+So I now have killed off *all* of the (static) ideas for this one. Anyone else have
+an idea???
 
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
-****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+From: Tucker Taft
+Sent: Monday, November 17, 2008  5:14 PM
+
+I think this is fairly straightforward.  The tagged type gets an abstract predefined
+"=" and if the tagged type is not itself abstract, then the "=" must be overridden.
+This would be true similarly if its parent type had an abstract "=".
 
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
+From: Tucker Taft
+Sent: Monday, November 17, 2008  4:57 PM
+
+I guess I would also allow you to "squirrel away" the predefined "="
+by renaming it before it was overridden.  I'm not sure whether you intended that
+to be illegal as well, but it is frequently useful.
+
 ****************************************************************
+
 From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+Sent: Monday, November 17, 2008  7:11 PM
 
+This one is turning out to be more complicated than I expected. I've attached
+another attempt at a !discussion and !proposal section, featuring (by popular
+demand) support for squirreling renames of equality operations that are going
+to be overridden by abstract functions. [This one is version /03 of the AI - Editor.]
+
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
+From: Tucker Taft
+Sent: Monday, November 17, 2008  8:16 PM
+
+> [Even if #2 and #3 get the usual boilerplate about rechecking in an 
+> expanded spec, there is still a question about violations within an 
+> expanded body. What are the dynamic semantics of a call to an 
+> overrider-pending "=" operator of a type derived from a formal private 
+> untagged type where the actual turns out to be a record type (tagged 
+> or untagged)? Or do we assume the worst and reject the generic body?]
+
+I think you assume the worst in a generic body.  That is, if you derive in
+the body from a nonlimited, untagged formal private type, you should presume it
+might be an untagged record type, and enforce the restrictions.  I can't imagine
+this will be too constraining!
+
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
+From: Pascal Leroy
+Sent: Tuesday, November 18, 2008  2:30 PM
+
+> 1) The "composed" equality operator for a type with a component
+>    whose primitive "=" operator is abstract is also abstract.
+>    In the case of a nonabstract tagged type, this operator would
+>    have to be overridden just like any other abstract operation
+>    (ditto in the case of a nonabstract extension of a parent type
+>    which has an abstract "=" operator).
+
+Rewording 3.9.3(4/2-6/2) to add this rule to the mix is going to be great fun.
+
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
 
+From: Randy Brukardt
+Sent: Thursday, December 4, 2008  11:19 PM
+
+> I think you assume the worst in a generic body.  That is, if you 
+> derive in the body from a nonlimited, untagged formal private type, 
+> you should presume it might be an untagged record type, and enforce 
+> the restrictions.  I can't imagine this will be too constraining!
+
+Humm; generally we want regular private types and formal private types to work
+the same way. And even though Mr. Private is (mostly) retired, I doubt that
+we want to break privacy to make such a check. So I think we have to enforce
+these restrictions on *all* untagged private types (because they might actually
+be an untagged record type).
+
+For instance:
+
+    package P is 
+       type Priv is private;
+    private
+       type Priv is access ...; -- (1)
+       -- type Priv is null record; -- (2)
+    end P;
+
+    with P;
+    package Q is
+       type New_Priv is new Priv;
+    private
+       function "=" (Left, Right : New_Priv) return Boolean; -- (3)
+    end Q;
+
+We can't allow (3) to be legal (it would violate Steve's condition #2), even
+though the full type is an access type. Because if we did, a change from the
+full declaration (1) to (2) would make it illegal, and that would be very bad
+(totally privacy breaking).
+
+So I don't think we need to worry about when it would be legal in a generic
+instance, since the usage has to be illegal all of the time in the template.
+
+I cannot get too worried about incompatibilities that only occur for derived
+untagged types (they don't happen much) with overriding routines (they almost
+never happen). But it is a wider set of incompatibilities than we originally
+envisioned.
+
 ****************************************************************
-From: Steve Baird
-Sent: Monday, November 17, 2008  7:20 PM
+
+From: Randy Brukardt
+Sent: Thursday, December 4, 2008  11:26 PM
+
+Why do I feel like this AI is like a sinkhole? If you get too close to the
+edge, another chunk breaks off and falls into the ever-widening pit... ;-)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent