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

--- ai05s/ai05-0214-1.txt	2010/12/15 00:10:59	1.4
+++ ai05s/ai05-0214-1.txt	2011/02/11 04:31:19	1.5
@@ -1,4 +1,4 @@
-!standard  3.7(9.1/2)                                10-11-22  AI05-0214-1/03
+!standard  3.7(9.1/2)                                11-02-10  AI05-0214-1/04
 !standard  3.7.2(3)
 !class amendment 10-06-12
 !status work item 10-06-12
@@ -41,18 +41,20 @@
 
 Modify 3.7.2(3):
 
-A'Constrained
-    Yields the value True if A denotes a constant, a value, [or] a constrained
-    variable{, or is known to be constrained}, and False otherwise.
-
-AARM Reason: Objects that are known to be constrained, which include all tagged
-objects (as nonlimited tagged types cannot have discriminant defaults, 
-and limited tagged objects are immutably limited) always are considered constrained
-by this attribute to avoid distributed overhead for parameters of limited classwide
-types, as limited tagged objects may technically be unconstrained if they use
-defaulted discriminants. Such objects still cannot have their discriminants changed,
-as assignment is not supported for them, so there is no use for this attribute
-that would justify the overhead of passing it with all classwide parameters.
+  A'Constrained
+    Yields the value True if A denotes a constant, a value, {a tagged
+    object,} or a constrained variable, and False otherwise.
+
+    AARM Reason: All tagged objects are known to be constrained (as
+    nonlimited tagged types cannot have discriminant defaults, and
+    limited tagged objects are immutably limited), and are always
+    considered constrained by this attribute to avoid distributed
+    overhead for parameters of limited classwide types, as limited
+    tagged objects may technically be unconstrained if they use
+    defaulted discriminants. Such objects still cannot have their
+    discriminants changed, as assignment is not supported for them, so
+    there is no use for this attribute that would justify the overhead
+    of passing it with all classwide parameters.
 
 !discussion
 
@@ -60,20 +62,33 @@
 various semantic problems. However, limited tagged types aren't really mutable;
 their discriminants cannot be changed after creation as no assignment is
 allowed. Thus there is no problem allowing defaults for discriminants on
-limited tagged types.
+limited tagged types, and there is some advantage when defining abstractions
+where the defaults can provide a useful simplification in usage.
 
-There is one small glitch. Currently, 'Constrained is True for all tagged
-objects. This change threatens to change that. Unfortunately, such a change
-has distributed overhead as parameters of class-wide types would have to
-assume that there is a future extension that has defaulted discriminants,
-and thus the value of 'Constrained would have to be passed with the parameter.
-Since 'Constrained is not useful for limited types, this is pointless.
-
-Thus we define 'Constrained to be True for all tagged objects, regardless of
-the form of their discriminants. We considered a more consistent rule which would 
-define objects of nonformal limited tagged types to be constrained
-by their initial value, but it required too many wording changes for a "simple"
-change.
+There is one small glitch. Currently, 'Constrained is True for all
+tagged objects. Allowing defaults threatens to change that. But such a
+change would have distributed overhead as parameters of limited
+class-wide types would require that 'Constrained be passed with the
+parameter, since its value would depend on whether explicit discriminant
+values were given at the point of declaration of the object. Since
+'Constrained is not useful for limited types, this is pointless.
+
+Thus we define 'Constrained to be True for all tagged objects,
+regardless of the form of their discriminants. We considered a different
+rule which would define all objects of a tagged type to be constrained
+by their initial value, but it required too many wording changes for a
+"simple" change. We also considered generalizing this rule to cover all
+immutably limited types, but that created an unnecessary inconsistency,
+since currently such types, if they have defaulted discriminants, can
+have objects for which 'Constrained is False. (Though currently some
+compilers return True for 'Constrained of such objects, so clearly this
+is not a thoroughly tested "feature" of the language.) This does imply
+that the value of the 'Constrained attribute could be used to discover
+whether the type of a parameter is tagged "deep down," even though that
+is not visible at the point of the use of the attribute. In this sense,
+preserving the rule that tagged objects always have 'Constrained of True
+provides a way to break privacy, though only at run-time (which is not
+usually considered an issue).
 
 !example
 
@@ -385,6 +400,41 @@
 
 I don't think this change would have any effect one way or the other on the
 implementation of build-in-place, but that's ok.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, February 10, 2011  9:49 PM
+
+Here is an update to AI 214.  [This is version /04 - Editor.]
+This is sort of back to the future.  We have gone around a couple of times on
+this.  It is back to saying that 'Constrained is True for all tagged objects,
+even if they have defaulted discriminants.  It isn't the most consistent way of
+looking at things (it would have been much more sensible in my view to say that
+if the nominal subtype is "known to be constrained" then the object is
+constrained by its initial value, and 'Constrained is True), but upward
+consistency argued for minimal change.  It does mean that 'Constrained is a way
+for discovering whether the full type for a limited private type is in fact
+tagged, but only at run-time.  Whatever...
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, February 10, 2011  10:28 PM
+
+There is no privacy at runtime - for almost everything the views don't matter. I
+think it somewhat misleading to suggest that it would "break privacy"; I don't
+see this is being much different than the fact that you can tell whether a
+parameter of a private type was passed by copy or by reference (and thus learn
+something about the kind of type: if it is passed by-reference it cannot be an
+elementary type, for instance). In neither case can you learn anything reliably:
+if 'Constrained is False, you can be sure the type isn't tagged, but
+'Constrained being True tells you nothing (the actual object might have been
+constrained, and there is no way to differentiate that from the tagged case).
+You could use it this way only with the cooperation of the caller, and at that
+point it would be more reliable to just read the source code. :-) Since the
+"break privacy" statement seems scary, and it isn't really able to tell you
+anything, I think you should just drop that whole point.
 
 ****************************************************************