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

--- ai05s/ai05-0247-1.txt	2011/03/29 07:13:55	1.4
+++ ai05s/ai05-0247-1.txt	2011/04/02 07:30:36	1.5
@@ -4939,3 +4939,151 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Wednesday, March 30, 2011  9:43 PM
+
+I would like to push back a bit on the question of whether to use subtype
+conformance for controlling legality in these cases involving Pre'Class.
+
+Historically speaking, we consolidated for Ada 95 the various levels of
+conformance between subprogram profiles because we saw various places where
+similar rules appeared in Ada 83, without any kind of encompassing concept.
+Each matching rule seemed distinct, some pickier than others (e.g. overloading
+was based on types matching, formal subprograms depended on modes and types
+matching, our new access-to-subprogram required subtypes to match, etc.).  By
+bringing them together in a single section, and establishing a hierarchy of
+conformance levels (type, mode, subtype, full), we hoped to bring some structure
+to the rules, and make sure no two matching rules were arbitrarily inconsistent.
+
+I understand that changing the definition of something like "subtype
+conformance" is scary, but I think it is worse to go back to sprinkling rules
+about the manual relating to matching rules between subprogram profiles.
+Furthermore, subtype conformance was invented precisely for "indirect-call-ish"
+situations, such as calling through an access-to-subprogram value, a dispatching
+call, and renaming as body.
+
+Issues with Pre'Class seem very much related to indirect calls, where the caller
+might not know statically what subprogram body is actually being invoked, and
+the body has certain minimum expectations about what Pre'Class aspect has been
+checked.  To me, this means subtype conformance should be adjusted to take
+Pre'Class into account, rather than distributing special rules about Pre'Class
+matching or weakening or whatever to all of the places where indirect calls
+appear.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, March 31, 2011  1:40 AM
+
+> I would like to push back a bit on the question of whether to use
+> subtype conformance for controlling legality in these cases involving
+> Pre'Class.
+
+Fair enough...
+
+> Historically speaking, we consolidated for Ada 95 the various levels
+> of conformance between subprogram profiles because we saw various
+> places where similar rules appeared in Ada 83, without any kind of
+> encompassing concept.  Each matching rule seemed distinct, some
+> pickier than others (e.g. overloading was based on types matching,
+> formal subprograms depended on modes and types matching, our new
+> access-to-subprogram required subtypes to match, etc.).  By bringing
+> them together in a single section, and establishing a hierarchy of
+> conformance levels (type, mode, subtype, full), we hoped to bring some
+> structure to the rules, and make sure no two matching rules were
+> arbitrarily inconsistent.
+>
+> I understand that changing the definition of something like "subtype
+> conformance" is scary,
+
+It's not scary, it is wrong.
+
+> but I think it is worse to go
+> back to sprinkling rules about the manual relating to matching rules
+> between subprogram profiles.
+
+That's not what I'm proposing.
+
+> Furthermore, subtype conformance was invented precisely for
+> "indirect-call-ish" situations, such as calling through an
+> access-to-subprogram value, a dispatching call, and renaming as body.
+
+Right. And you are proposing breaking those.
+
+> Issues with Pre'Class seem very much related to indirect calls, where
+> the caller might not know statically what subprogram body is actually
+> being invoked, and the body has certain minimum expectations about
+> what Pre'Class aspect has been checked.  To me, this means subtype
+> conformance should be adjusted to take Pre'Class into account, rather
+> than distributing special rules about Pre'Class matching or weakening
+> or whatever to all of the places where indirect calls appear.
+
+I think you should actually go read my proposed AI, rather than talking about
+alternatives that don't make any sense. And/or read my mail more carefully.
+
+First of all, you are proposing changing subtype conformance in some way that
+doesn't make sense. My understanding is that you want to change it to require
+Pre'Class to match in some but not all cases (in particular, you want
+overloading subprograms to be able to specify an additional Pre'Class). That can
+only be accomplished by adding an entirely new kind of conformance, or some
+truly bizarre rules for overriding. Neither of those will accomplish the goal of
+simplifying the rules.
+
+Second, (most) renames don't actually use subtype conformance. Your explanation
+was that we only cares about overriding renames. But as noted above, you want
+overriding to *not* be subject to this rule - it *cannot* require Pre'Class
+matching. So the entire proposal you are making makes no sense - you still need
+a special case rule for renames.
+
+Third, overriding also comes up in "implemented-by", so if you design a "wording
+hack" to deal with overriding, it has to be spread around to these other places
+as well.
+
+Fourth, most of the uses of subtype conformance don't care about preconditions.
+(For instance profile matching for access-to-subprograms in type conversions,
+equality, and generic access actuals). You're adding a complication there.
+
+Fifth, subtype conformance is used in full conformance. 8.3(12.3/2) uses full
+conformance, so you would be requiring Pre'Class matching on inherited
+subprograms -- that would require overriding in various interface cases. (And
+that requirement would not be enough to eliminate the null subprogram problems,
+so we'd still need other rules for that.)
+
+Lastly, I don't buy the need to make the renames case illegal. Any "problem"
+disappears as soon as you consider it equivalent to the matching explicit body.
+Which is *exactly* the same rule that is being proposed to fix three other
+problems in this AI! Unless we decide to make all of those other cases illegal
+(technically, "requires overriding" - an explicit body has to be given), I
+cannot even justify making the renames case illegal. Why should someone have to
+write an explicit body rather than a renames (with the extra chances for error),
+when in similar cases with inherited subprograms, we're writing the body
+automatically?
+
+The only case that has any reason to be made illegal is the 'Access one, and
+that one is pretty dubious (the explicit body would work there, too, but for
+'Access we might not be somewhere where the declaration of an arbitrary body
+should be allowed).
+
+Thus I used a *single* rule to make 'Access illegal if the subprogram has a
+non-trivial Pre'Class. I did not "sprinkle rules around" because there are no
+such rules! If we need any additional rules, I would push to get rid of them by
+eliminating the illegal cases (it's not worth it).
+
+
+P.S. If you can do the impossible and make this work, please show me with actual
+wording proposals!! I think we've reasonably converged on what we want (at least
+in broad terms) and we need to figure out how to accomplish that. I've spend the
+better part of three days writing an AI on this topic, including telling you
+repeatedly why this idea of yours won't work, and I've gotten hardly any
+constructive feedback. (Only "isn't there another approach?" -- to which the
+answer is, not really.) So show me something I haven't considered instead of
+stuff I already know don't work!!!
+
+And please note that I've been writing this AI to keep you from being
+overburdened so that you can finish your other homework. (BTW, please do your
+other homework. ;-) But it doesn't pay for me to spend more time on it if you
+are going to virtually ignore it in favor of things that clearly don't work.
+Constructive ideas are welcome - rehashing is not.
+
+****************************************************************
+