CVS difference for ai05s/ai05-0234-1.txt
--- ai05s/ai05-0234-1.txt 2010/11/19 04:36:43 1.3
+++ ai05s/ai05-0234-1.txt 2011/01/27 06:06:17 1.4
@@ -1595,3 +1595,144 @@
+From: Steve Baird
+Sent: Tuesday, January 25, 2011 5:40 PM
+Ok, I'll produce wording.
+Here are the two mail messages on the subject that were sent earlier.
+As usual, any feedback will be appreciated.
+==== Message #1 ====
+When an object is built in place, the anonymous object and the object being
+initialized which it "mutates" into (as described in 7.6(17.5/3) and following)
+may have different accessibility levels.
+In some cases this leads to problems when a dynamic accessibility check is
+performed against the object's current accessibility level rather than against
+the level it is eventually going to have.
+AI05-0051 deals with parts of this situation by performing checks against an
+accessibility level "as determined by the point of call" but it appears that
+some cases involving coextensions are are not handled correctly (and the precise
+meaning of this wording is not obvious).
+In the case of an aggregate, the situation is even worse.
+There are no dynamic accessibility checks associated with the evaluation of an
+aggregate, presumably because it was believed that there was no way for the
+anonymous object of the aggregate to contain a reference to something more
+short-lived than itself.
+This is certainly false if mutation occurs, as illustrated by one of the
+examples given in this AI.
+To address this, I think we need to bite the bullet and define an "ultimate"
+(perhaps "post-mutation" or "eventual" would be better terms?) accessibility
+level for a type or object.
+Roughly speaking, this is the accessibility level that an object will have after
+all the mutating has finished.
+This is a dynamic notion and is only used in the definition of dynamic
+ The ultimate accessibility level of an anonymous
+ function_result/aggregate object which is
+ built in place is the ultimate accessibility level of the
+ object that the anonymous object is being used to initialize.
+ Ditto for the ultimate accessibility level of the
+ named function return object of an extended return statement.
+ The ultimate accessibility level of the access type
+ of an allocator which creates a coextension, and of the
+ coextension objct itself, is the ultimate accessibility level
+ of the coextension's owner.
+ The ultimate accessibility level of an anonymous access
+ type which is a result type for a dispatching
+ function which is called via a dispatching call
+ is the ultimate accessibility level of the
+ result type of the function called by the caller.
+ This case has nothing to do with build in place, but
+ I think we still need to include this case in order to
+ get the definition right.]
+ For all other entities, the ultimate accessibility
+ level of the entity is the same as its accessibility level.
+For example, if an allocator is initialized by calling function Foo which in
+turn returns the result of calling function Bar (with b-i-p at every step) then
+the ultimate accessibility level of Bar's function result object is that of the
+ We need to look at the interactions between this
+ definition and optional (as opposed to required)
+ build-in-place. I don't know of any problems in
+ this area, but it is something to keep in mind.]
+The checks where we currently (see AI05-0051) use "as determined at the point of
+call" wording would be modified to become checks against the ultimate
+accessibility level of the object/type in question.
+I think his would address the corner case problems with coextensions that we
+have discussed earlier in the context of this AI.
+In the [rare] case of an aggregate of a discriminated type having one or more
+access discriminants for which defaults are provided, a dynamic accessibility
+check is performed of the accessibility level of each discriminant value against
+the ultimate accessibility level of the anonymous object of the aggregate.
+The check can be omitted in the case where the subtype of the object being
+initialized is constrained, or when the discriminant value is the result of
+evaluating the discriminant's default expression.
+ Typically a dynamic accessibility check has a corresponding static
+ legality rule to prohibit the cases where it is statically
+ known that the dynamic check would fail. Static rules corresponding
+ to the dynamic checks described in this proposal would
+ need to be considered, but they might not be needed because
+ typically these rules involve knowledge about both sides of a call.
+ Perhaps something like an aggregate used to initialize an allocator
+ with no calls in sight would warrant a check?]
+ We need to confirm that this is straightforward to implement.
+ I think that the "pass in an accessibility level
+ parameter" model described in AI05-0051 suffices, but this
+ needs confirmation.]
+==== Message #2 ====
+I hate to hair this proposal up with complexity that is specific to
+coextensions, but I think the "ultimate accessibility level" definition for a
+coextension (and for its access type) needs to take into account transfer of
+coextension ownership in the non-bip case (i.e., 3.10.2(14.4/3), as it applies
+in the non-bip case).
+The definition I outlined earlier already handles this ownership transfer in the
+b-i-p case because there really isn't a transfer in that case (the old owner
+mutates into the new one).
+The idea is that the ult-acc-lev of a coextension is the ult-acc-lev not of its
+current owner, but of the object which will end up being its owner.
+Would an example illustrating the need for this be useful?
+In some sense, this wrinkle strengthens the case for the general "ultimate
+accessibility level" approach.
+The "ultimate accessibility level" of an object is a complicated idea, but by
+factoring out all this complexity into one place (i.e., the definition of the
+term), we can plug holes in lots of places in the RM by using this new term in
+defining various dynamic accessibility checks.
Questions? Ask the ACAA Technical Agent