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

--- ai05s/ai05-0083-1.txt	2008/01/17 07:24:41	1.1
+++ ai05s/ai05-0083-1.txt	2008/03/08 05:33:45	1.2
@@ -1,16 +1,19 @@
-!standard 13.3(23/2)                                         08-01-17    AI05-0083-1/01
+!standard 13.1(11/2)                                       08-03-07    AI05-0083-1/02
+!standard 13.4(22/2)
 !standard 13.3(40)
-!class binding interpretation 08-01-17
+!class ramification 08-02-10
 !status work item 08-01-17
 !status received 07-12-23
 !priority Low
-!difficulty Hard
+!difficulty Easy
 !qualifier Clarification
 !subject Representation values of formal parameters
 
 !summary
 
-** TBD **
+Representation values such as 'Size and 'Alignment can have different values for
+a formal parameter than for the associated actual parameter, even when the
+parameter is passed by reference (and thus is a view of the object).
 
 !question
 
@@ -64,42 +67,45 @@
 
 !wording
 
-** TBD **
+Add an AARM Ramification after 13.1(11.c/2):
 
+However, this does not apply to objects. Different views of an object can have
+different representation aspects. For instance, an actual object passed
+by reference and the associated formal parameter may have different values for
+Alignment even though the formal parameter is merely a view of the
+actual object. This is necessary for the language design principle
+that Alignments are always known at compile time to be true.
+
 !discussion
 
-For alignment, both possible meanings seem bad. The meaning of "object" is
+For alignment, the meaning of "object" (rather than "view of an object") is
 bad because it requires the implementation to pass the alignment along with
-the formal parameter. (That wouldn't be necessary for a by-copy parameter,
-which is a new object, but that just makes things more confusing.) Moreover,
-it limits the reasoning that can be done about the alignment of the
-passed object.
-
-The second is bad because returning 0 or 1 for the alignment of all parameters
-would be a correct implementation. This means that a programmer couldn't assume
-anything about the alignment, even though the alignment is specified for the
-subtype of the parameter - there would be no way to control the alignment
-of a formal parameter. Moreover, the real alignment of the object is hidden.
-
-It would seem best if the alignment of a formal parameter was that of the
-subtype of the parameter. In that case, the parameter's alignment can be
-specified with a suitable subtype. But there doesn't seem to be any way to
-come up with that answer from the wording of the standard.
-
-Note that the answers for other attributes don't necessarily need to be
-the same.
-
-For instance, for Size of an unconstrained formal object, the Size of the
-actual is likely to be more useful than the Size of the formal type (which
-is likely to be a very large number). OTOH, it would be best if the result
-could be calculated from the array descriptor, rather than being required
-to be passed in.
-
---!corrigendum 13.9(7)
+the actual parameter if by-reference. (That wouldn't be necessary for a
+by-copy parameter, which is a new object, but that just makes things
+more confusing.) Moreover, it limits the reasoning that can be done
+about the alignment of the passed object.
+
+Luckily, AI05-0080-1 says that "view of" is almost always meant (implicitly)
+in Static Semantic and Legality Rules. (And the "almost" was simply being
+conservative; no one has an example of a rule for which it is not meant,
+simply because such a rule would violate privacy.) As such, the language
+clearly means that the alignment can be different for different views.
+This even works for aspects of (sub)types, as all views of a type must have
+the same aspect values (by 13.1(11/2)).
+
+The Language Design Principle given in 13.3(21.d) provides more evidence
+for this intepretation. It says that the alignment should always be
+known at compile-time.
+
+Thus we conclude that the language is clear. Param'Alignment in the example
+of the question can be 2 (and be known at compile-time) even though
+Lim_Obj'Alignment (the actual object) is 4.
 
 !ACATS Test
 
-** TBD **
+In theory, no new ACATS tests are needed, although it might be worthwhile
+to check the existing tests to verify whether Alignment is tested in this
+way.
 
 !appendix