CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2000/03/27 18:17:34	1.16
+++ ais/ai-00224.txt	2000/03/28 01:25:56	1.17
@@ -3604,3 +3604,142 @@
 
 *************************************************************
 
+From: Tucker Taft
+Sent: Monday, March 27, 2000 2:53 PM
+
+Robert Dewar wrote:
+> ...
+> <<I wonder whether we should fix this suppress...on to be more
+> useful?  It certainly seems like the suppress...on should be based
+> on the LHS rather than the RHS of an assignment, even though the
+> RM semantics describe the assignment check in terms of a subtype
+> conversion applied to the RHS.
+> >>
+>
+> I am not sure who "we" here is. If "we" is Intermetrics, feel free to
+> do whatever you like here :-)
+>
+> If you are suggesting that we try to define which entities should be checked
+> in this and other situations, then I will repeat something I said a long
+> time ago ... "that way likes madness".
+
+It might be nice for uniformity to at least draft a set of
+implementation advice for suppress...on, so that over time
+our implementations might converge.  I am also curious whether
+there is any consensus on what is desirable/intuitive for suppress..on
+an object and how it relates to LHS and RHS of an assignment.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 4:33 PM
+
+<<It might be nice for uniformity to at least draft a set of
+implementation advice for suppress...on, so that over time
+our implementations might converge.  I am also curious whether
+there is any consensus on what is desirable/intuitive for suppress..on
+an object and how it relates to LHS and RHS of an assignment.
+>>
+
+I have no intuition here except to try to follow the RM, which suggests
+that it is the subtype that is the relevant entity.
+
+If you start trying to draft implementation advice here you will get into
+a mess, particularly if you start trying to be pragmatic and figure out
+what is useful.
+
+Tuck, I guess you have not thought about this issue before. It is in fact
+very familiar to me, and after all dates back to Ada 83 days. This has
+always been a crufty part of the language, and my view is that it is wasted
+effort to try to "fix" it.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Monday, March 27, 2000 3:45 PM
+
+I agree with Robert here.  It's a waste of time to try to define any of
+this "On=>" stuff, even as impl advice.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 27, 2000 4:08 PM
+
+Is this because you think the feature should not be in the language?
+From my perspective, as long as it is in the language, we ought to
+at least attempt to have some common approach to supporting it,
+or at least enumerate the possibilities for the poor user, so they
+can conclude using Suppress...On is very implementation dependent.
+
+The current implication in the RM that Suppress...On is well-defined
+is quite misleading.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 4:58 PM
+
+<<Is this because you think the feature should not be in the language?
+>>
+
+Right, it was a mistake, it has never been well defined, but this is
+"well known" at this stage, and this is such an unimportant marginal
+feature that it is just not worth worrying about.
+
+I really think you are going to have a hard time getting anyone to
+notice this issue, and if you do come up with a set of implementation
+advice, I can't imagine spending any time trying to conform to it.
+
+It would be unhelpful even to say that this was implementation defined,
+because it would make implementations waste time documenting junk.
+
+Yes, I understand the general principle that portability is nice, but
+there are pragmatic limits :-)
+
+*************************************************************
+
+From: Dan Eilers
+Sent: Monday, March 27, 2000 5:20 PM
+
+> Is this because you think the feature should not be in the language?
+
+On behalf of ICC, I'd like to vote for removing this feature from the
+language, so long as implementations were permitted to implemented it
+for backwards compatibility with previous versions of the standard.
+
+Our compiler does not implement Suppress...On, since we detect no
+user interest in this feature.  We might change our minds if some
+survey of users showed some interest.
+
+We suspect that there might be a better way to satisfy whatever user
+need there might be for Suppress...On.  For example, if a user is
+suppressing access checks because objects of a particular access type
+are known never to be Null, then a better approach would probably be
+a pragma restriction non_null, so that violations of this constraint
+could be detected on assignment rather than on dereferrence.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 5:35 PM
+
+<<Our compiler does not implement Suppress...On, since we detect no
+user interest in this feature.  We might change our minds if some
+survey of users showed some interest.
+>>
+
+Well I trust you implement it to the point of recognizing it and ignoring
+it (otherwise you could not sign the declaration of conformance). But
+ignoring it is certainly quite acceptable.
+
+<<On behalf of ICC, I'd like to vote for removing this feature from the
+language, so long as implementations were permitted to implemented it
+for backwards compatibility with previous versions of the standard.
+>>
+
+Well there is no point in removing this, since that just causes unnecessary
+incompatibilities, and implementing it is zero effort for compilers.
+
+*************************************************************
+