CVS difference for ai05s/ai05-0234-1.txt
--- ai05s/ai05-0234-1.txt 2011/02/08 08:21:06 1.5
+++ ai05s/ai05-0234-1.txt 2011/02/16 06:15:23 1.6
@@ -157,7 +157,7 @@
each such access discriminant, as determined by the expression provided
in the aggregate, is not deeper than the ultimate accessibility level
of the anonymous object created for the evaluation
- of the aggregate. If this check fails, Program_Error is raised.
+ of the aggregate. If this check fails, Program_Error is raised.
AARM note:
This check is guaranteed to pass in the (usual) case that
@@ -173,26 +173,24 @@
Modify 4.8(10.1/3) as (modified by AI05-0024-1 and AI05-0051-1) as
-follows:
+follows (splitting it into three paragraphs):
- For any allocator, if the designated type of the type of the
- allocator is class-wide, then a check is made that the
- accessibility level of the type determined by the
- subtype_indication, or by the tag of the value of the
- qualified_expression, includes the elaboration {of the ultimate
- master} of the type of the allocator. If the subtype determined by
- the subtype_indication or
- qualified_expression {(or by the tag of the value of the qualified
- expression if the type of the qualified expression is class-wide)}
- of the allocator has one or more access discriminants, then a
- check is made that the accessibility level of the anonymous access
- type of each access discriminant is not deeper than [that]{the
- ultimate accessibility level} of the type of the allocator.
- Program_Error is raised if either such check fails.
-
-[Editor's note: Steve said he wanted other changes as well, but I can't figure
-out what they are supposed to be; he did not show them, rather describing
-what to change from some unknown baseline.]
+ For any allocator, if the designated type of the type of the
+ allocator is class-wide, then a check is made that the master
+ of the type determined by the subtype_indication, or by the
+ tag of the value of the qualified_expression, includes
+ the elaboration of the {ultimate master of the} type of the
+ allocator.
+
+ If the subtype determined by the subtype_indication or
+ qualified_expression {(or by the tag of the value of the
+ qualified expression if the type of the qualified expression is
+ class-wide)} of the allocator has one or more access discriminants,
+ then a check is made that the accessibility level of the anonymous
+ access type of each access discriminant is not deeper than [that]
+ {the ultimate accessibility level} of the type of the allocator.
+
+ Program_Error is raised if either such check fails.
In 6.5(8) replace
@@ -219,7 +217,7 @@
not deeper than the [level of the return object as determined by the
point of call]{ultimate accessibility level of the
return object} (see 3.10.2). If this check fails, Program_Error is
- raised.
+ raised.
[Editor's note: Steve referenced 7.6 instead on 3.10.2 here. But that makes
no sense, the "ultimate accessibility level" is defined in 3.10.2, so
@@ -233,7 +231,7 @@
adding
"whose value is not constrained by the result subtype of the function" .
What does this wording mean if the result subtype is
-Some_Constrained_Subtype'Class ? Like a zombie, AI05-0057 refuses to
+Some_Constrained_Subtype'Class? Like a zombie, AI05-0057 refuses to
stay buried. [Editor's comment: The same thing that it means anywhere
else -- which we can't agree on. I don't see anything different here.]]
@@ -1863,5 +1861,258 @@
well use it elsewhere (see above changes to 4.8 and 6.5)
even though the only holes that this fixes are related to coextensions
(and are therefore less important, at least to some folks).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, February 14, 2011 1:17 PM
+
+Question #1 -
+
+Are there interactions between this "ultimate" stuff and aliased paraemters?
+Do we also need to add an "ultimate" to the wording for the runtime accessibility check associated with an aliased parameter?
+
+6.4.1(15.1/3):
+ In a function call, for each explicitly aliased parameter, a check is
+ made that the accessibility level of the master of the actual object
+ is not deeper than that of the {ultimate} master of the
+ function result.
+
+As semantics-preserving polishing, we could then (if it reads better) replace
+ "that of the ultimate master of the function result"
+with
+ "the ultimate accessibility level of the function result"
+
+The general idea is that if the function result is going to contain a reference
+to the parameter, then the parameter must not be shorter-lived than the function
+result.
+
+Inside a function, consider, for example, a subaggregate of a b-i-p function
+result aggregate of the form
+
+ (Access_Discriminant => Aliased_Formal_Parameter'Access)
+
+where the function is declared in a nested scope but the function call is used
+to initialize an allocator whose access type is declared in a less-nested scope
+(e.g., library level).
+
+Question #2 -
+ Given the current wording for this AI (i.e., with no mention
+ of any special rules for aliased parameters), the call to the
+ function would not fail (at the point of the call), but would
+ the aggregate's evaluation fail inside the function? This boils
+ down to a question about the dynamic accessibility level of an
+ aliased formal parameter.
+
+ The already-proposed AI-234 wording for aggregates includes
+ ... a check is made that the accessibility level of the
+ anonymous access type of each such access discriminant,
+ as determined by the expression provided
+ in the aggregate, is not deeper than the ultimate accessibility
+ level of the anonymous object created for the evaluation
+ of the aggregate.
+
+ What is the (dynamic) accessibility level "determined by the
+ expression provided" in this case? Does this need some wording?
+
+With the addition of the above-proposed runtime accessibility check, it would be
+safe to define the (dynamic) accessibility level of an aliased formal parameter
+to be the ultimate accessibility level of the function result (at least in the
+case of a function with a non-elementary result type).
+
+Does this seem like the right thing to do?
+
+If it seems like this "ultimate" stuff is getting out of hand, don't shoot the
+messenger. I'm just trying to work out the consequences of allowing an object to
+change masters.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2011 1:19 PM
+
+This is certainly a painful area.
+
+I would hope we could move most of the "dynamic semantics"
+wording of 3.10.2 into AARM notes. For example, I don't think we need to
+enumerate in the normative wording all the ways that the master of an object can
+change. Also, I would much prefer bullets to a series of unbulleted paragraphs
+that are closely parallel with one another. All in all, I would hope we could
+reduce the amount of normative wording associated with this issue down to the
+bare minimum, with most of the rest in the AARM. Steve, do you think this might
+be possible?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, February 14, 2011 1:37 PM
+
+> This is certainly a painful area.
+That's a polite choice of words.
+
+>
+> I would hope we could move most of the "dynamic semantics"
+> wording of 3.10.2 into AARM notes.
+Certainly a worthy goal.
+
+>For example, I don't think
+> we need to enumerate in the normative wording all the ways that the
+>master of an object can change.
+Sounds right.
+
+> Also, I would much
+> prefer bullets to a series of unbulleted paragraphs that are closely
+> parallel with one another.
+Makes sense.
+
+> All in all, I would
+> hope we could reduce the amount of normative wording associated with
+> this issue down to the bare minimum, with most of the rest in the
+> AARM. Steve, do you think this might be possible?
+I'll make a pass through it with this in mind, but I think you may have
+identified the low-hanging fruit.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011 2:36 PM
+
+> Question #1 -
+>
+> Are there interactions between this "ultimate" stuff and aliased
+> paraemters?
+> Do we also need to add an "ultimate" to the wording for the runtime
+> accessibility check associated with an aliased parameter?
+
+Tucker and I were assigned to figure out issues associated with aliased
+parameters and this AI. I think I speak for both of us when I say that I am glad
+that you are taking that over from us. ;-)
+
+The quick answer to your question is yes, but I don't know if it really matters.
+(The intent was always that the check is against the caller's version of that
+accessibility; isn't that the same as the "ultimate accessibility"??)
+
+...
+> Inside a function, consider, for example, a subaggregate of a b-i-p
+> function result aggregate of the form
+>
+> (Access_Discriminant => Aliased_Formal_Parameter'Access)
+>
+> where the function is declared in a nested scope but the function call
+> is used to initialize an allocator whose access type is declared in a
+> less-nested scope (e.g., library level).
+
+I'm certain this case is already covered; that was the entire point of the check
+(this case). If it *isn't* covered, then nothing is right. The only cases that
+might not be covered have to do with the transfer of coextensions in non-b-i-p
+calls, but even there I thought that it was already covered.
+
+It still might be better to use the "ultimate" wording simply to reassure
+everyone that these are the same, but I don't think it is necessary.
+
+> Question #2 -
+> Given the current wording for this AI (i.e., with no mention
+> of any special rules for aliased parameters), the call to the
+> function would not fail (at the point of the call), but would
+> the aggregate's evaluation fail inside the function? This boils
+> down to a question about the dynamic accessibility level of an
+> aliased formal parameter.
+
+I don't understand this question; everything about accessibility of aliased
+parameters is already special. If there is something that isn't, it is wrong.
+(Tucker would like to change that for uses not inside of a return statement, but
+that is irrelevant to your rules.)
+
+...
+> With the addition of the above-proposed runtime accessibility check,
+> it would be safe to define the (dynamic) accessibility level of an
+> aliased formal parameter to be the ultimate accessibility level of the
+> function result (at least in the case of a function with a
+> non-elementary result type).
+
+That is what it is currently defined to be (or at least *supposed* to be defined
+to be), without the "ultimate" wording. Again, there is no change here that I
+can see (modulo wording bugs). Using "ultimate" might simplify the wording, but
+it won't change anything.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, February 14, 2011 3:54 PM
+
+> (The intent was always that the check is against the caller's
+> version of that accessibility; isn't that the same as the "ultimate
+> accessibility"??)
+
+Usually they are the same, but in the rare cases where they differ, I think we
+want the "ultimate" one.
+
+Certainly they can differ in cases involving coextensions.
+
+In a case like
+
+ return Some_Dispatching_Op (...);
+
+where both the function being called and the function being returned from have a
+controlling access result type, does the "caller's version of the accessibility"
+wording handle the case where *both* of the two calls involved are
+trans-accessibility-level (making up terminology on the fly here) dispatching
+calls?
+
+[By a trans-accessibility-level call, I mean a call (as described in AI05-0051)
+where the body executed by the call is declared in a more nested scope than the
+subprogram the caller is (statically) calling.]
+
+> ...
+>
+>> Question #2 -
+>> Given the current wording for this AI (i.e., with no mention
+>> of any special rules for aliased parameters), the call to the
+>> function would not fail (at the point of the call), but would
+>> the aggregate's evaluation fail inside the function? This boils
+>> down to a question about the dynamic accessibility level of an
+>> aliased formal parameter.
+>
+> I don't understand this question; everything about accessibility of
+> aliased parameters is already special. If there is something that
+> isn't, it is wrong. (Tucker would like to change that for uses not
+> inside of a return statement, but that is irrelevant to your rules.)
+
+I was only clarifying that by "the current wording for this AI", I meant wording
+that is at least 24 hours old, not something brand new that was introduced
+earlier in the same e-mail.
+
+I may well be missing something. Where should I be looking for the current
+definition of the (dynamic) accessibility level of an aliased formal parameter?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011 6:01 PM
+
+> I may well be missing something. Where should I be looking for the
+> current definition of the (dynamic) accessibility level of an aliased
+> formal parameter?
+
+I believe we are talking about 3.10.2(13.3/3). It even includes the word
+"ultimate"!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 15, 2011 2:28 AM
+
+BTW, Tucker and I semi-agreed on a fix to the static accessibility rule for
+formal explicitly aliased parameters. And we put that fix into AI05-0235-1. If
+there is anything that needs to be changed with their dynamic accessibility,
+we're leaving it to you to fix (in the paragraph noted above). I am of the
+opinion that everything will work fine inside of a function: the expectation is
+that the dynamic check always succeeds in cases of comparing return objects to
+aliased parameters. (The whole point was to eliminate the possibility of failure
+of the dynamic check).
+
+If there is a problem, it's probably with the check of the actual parameter's
+accessibility. These are 6.4.1(6.3/3) [static check] and 6.4.1(15.1/3) [dynamic
+check]. Enjoy. :-)
****************************************************************
Questions? Ask the ACAA Technical Agent