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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0143-1.txt

--- ai05s/ai05-0143-1.txt	2009/02/15 07:19:50	1.1
+++ ai05s/ai05-0143-1.txt	2009/05/01 00:21:27	1.2
@@ -1,12 +1,11 @@
-!standard 6.01 (18)                                 09-02-15  AI05-0143-1/01
+!standard 6.01 (18)                                 09-04-30  AI05-0143-1/02
 !standard 6.06 (03)
-!standard 9.5.1 (02)
 !class Amendment 09-02-15
 !status work item 09-02-15
 !status received 09-02-15
 !priority High
 !difficulty Medium
-!subject It's BAAACCKK!!: In Out parameters for functions
+!subject In Out parameters for functions
 
 !summary
 
@@ -70,16 +69,6 @@
 generic function has the corresponding number of parameters of mode in and no
 other parameters.
 
-Replace 9.5.1(2) by:
-Within the body of a protected function (or a function declared immediately
-within a protected_body), all of whose parameters have mode in, the current
-instance of the enclosing protected unit is defined to be a constant [(that is,
-its subcomponents may be read but not updated)]. Within the body of a
-protected subprogram other than a function with parameters of mode in (or a
-such a subprogram declared immediately within a protected_body), and within
-an entry_body, the current instance is defined to be a variable [(updating
-is permitted)].
-
 !discussion
 
 The primary technical argument against allowing "in out" and "out" parameters
@@ -103,20 +92,29 @@
 dependence is discussed in AI05-0144-1, including plenty of examples.)
 
 
-Two additional issues are addressed by this change.
-
 Operator symbols are conceptually functions with one or two in parameters.
 We do not want infix expressions to have side effects on their arguments.
 Thus, we add wording to restrict operator symbols to parameters of mode in.
+
 
-The unfortunate tying of read-only vs. read-write access to a protected object
-to the use of a function or procedure also needs to be changed. We've used the
-minimal fix here, which is to say that functions with in out or out parameters
-have read-write access to the protected object. A better solution would be
-to add a modifier similar to that used for overriding to determine whether a
-subprogram has read-only versus read-write access. However, that was rejected
-as being too heavy of a solution, particularly as Ada compilers rarely
-take advantage of read-only protected object access.
+We considered using the presense of "in out" parameters on a function to
+signal that the function needs read-write access to the protected object.
+This is a capability that is sorely missing from Ada, as the current rules
+force programmers to use procedures when they really want functions. As
+noted in the description of the initial problem, it is not always possible
+to convert a function into a similar procedure call, and even when it is
+possible, the result is harder to use than necessary.
+
+However, the presense of "in out" parameters doesn't really tell us whether
+or not we need write access to the protected object; it is perfectly reasonable
+to modify a parameter but not the protected object. This imperfect description
+is no better than the current situation in the eyes of some reviewers (an
+opinion not shared by the author).
+
+In addition, adding read-write function access to protected objects could
+have a significant impact on implementations. The problem is not judged
+important enough (and the solution not good enough) in order to incur this
+impact.
 
 !example
 
@@ -169,7 +167,7 @@
 
 ACATS tests are needed to test that this is allowed, and that the restrictions
 on operator symbols are enforced. Moreover, existing ACATS B-Test tests
-prohibiting in out parameters on function needs to be withdrawn.
+prohibiting in out parameters on functions need to be withdrawn.
 
 !appendix
 
@@ -188,5 +186,13 @@
 in that context. It's quite possible that the rule under discussion was later
 modified eliminating the problem, or perhaps it was never used at all. Or
 maybe I just failed to find it.
+
+****************************************************************
+
+From: Randy Brukardt, April 30, 2009
+
+The accessibility subcommittee discussed this AI during its conference call today,
+and it decided not to make the protected function change. The AI (now version /02)
+was thus rewritten to remove this change and discuss the reasons why.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent