!standard 3.10.2(13.1/2) 09-04-27 AI05-0142-3/02 !class Amendment 09-04-10 !status work item 09-04-10 !status received 09-04-10 !priority Medium !difficulty Medium !subject Accessors for Ada.Containers !summary (See proposal.) !problem Modifying a portion of a larger opaque object (such as a container) is not well-supported in Ada. The Ada.Containers packages provide a procedure Replace_Element for this purpose. But this procedure requires copying the element (potentially in both directions). That could be very expensive if the element is large. The Ada.Containers packages also provide an procedure Update_Element for this purpose; this provides a writable object as a parameter to a subprogram passed into the procedure. This procedure avoids the need to copy the element, but it is hardly convenient to define a procedure for every component of the element that needs changing. The extra syntax needed obscures the real meaning of the program. An option that was rejected for the Ada.Containers packages was to return an access to the element type. However, this is problematic as it is difficult to control the accessibility and lifetime of the returned access. If the element is removed from the container, the returned access could become dangling; continued use of the access would make the program erroneous. Moreover, the accessibility of the returned object (and thus what could be done with it) would depend on the actual implementation of the container. Bounded containers would typically only return access values with a very short lifetime, while unbounded containers would typically return access values with a much longer lifetime. Converting from an unbounded to bounded form could thus introduce new runtime errors - a serious maintenance hazard. !proposal (See wording.) !wording Pseudo-wording: Language Design Principles: The idea of the returnable parameter (see below) is that we will ensure at the call site that a part of it can be returned as part of the function result without creating a dangling pointer. We do this with a combination of static and dynamic rules (most of the dynamic rules can actually be evaluated at compiler-time, but doing so would break privacy or the generic contract -- we don't want legality rules that do either of these things.) Note that these rules don't need to be a perfect match between the call and inside the function -- it is harmless if the call thinks a parameter if returnable while the actual function body does not (this can happen inside of a generic, for instance). On the other hand, disaster could result if the call thinks it is passing a normal parameter (and thus makes no checks) while the body assumes the parameter was already checked. [I defined the terms "returnable parameter" etc. below in order that we don't distribute that definition all over the world. Currently, they only get used a few times, but that's fine. - RLB] Static Semantics (Definitions): A "returnable parameter" is one for which a part (or coextension) of the parameter can be returned as a function result. An "immutably returnable parameter" is a parameter with the following characteristics: * it is a parameter of a function with an anonymous access result, or a result subtype whose view has a part with an access discriminant; * if the function of which it is a parameter overrides a homograph and has a controlling result, the corresponding parameter in all overridden homographs is also an immutably returnable parameter; * the type of the parameter is tagged, or is a composite type that has a known discriminant part or is not a partial view. [Note: If we wanted to retain the original "non-*in*" wording, it would go here and in the next bulleted list.] AARM Reason: This is the definition for use in legality rules; these rules only apply to types that are composite and cannot become something else. The part about the homographs ensures that the "immutably returnable parameter" property does not change for dispatching calls. In particular, if some tagged type does not have an part with an access discriminant, any functions with controlling results that it defines will not have returnable parameters. If a descendent of that tagged type adds an access discriminant and overrides the function, we could dispatch to the function without the special accessibility checking. In that case, the function body better not assume that checking was performed, as it could allow it to return dangling pointers. We only have to worry about controlling results, as in other cases the return type of the dispatching routine cannot change. We need the messy wording excepting partial views as a private type is always considered composite and we don't want this to apply to parameters that have private types but are really elementary. [Note: For uses in calls, this is not strictly necessary, as it only would mean an extra check; but for uses inside of function bodies, this is critical so that parameters that were never checked are not used as if they were checked. OTOH, it is not certain that you could do anything that causes trouble with such a parameter, as it would not be passed by reference and would not allow 'Access, nor would it have any visible aliased components. So maybe we don't need the messy wording.] End AARM Reason. A "runtime returnable parameter" is a parameter with the following characteristics: * it is a parameter of a function with an anonymous access result, or a result subtype whose full view has a part with an access discriminant; * if the function of which it is a parameter overrides a homograph and has a controlling result, the corresponding parameter in all overridden homographs is also a runtime returnable parameter; * the full view of the type of the parameter is a composite type. AARM Reason: This is the definition for use in dynamic semantic checks. The homograph part of the rule is needed for the same reason as notied previously. Add a new Static semantics rule somewhere: For runtime returnable parameters of a function call, the master of the expression designating the actual parameter is that of the function result (rather than the master of the function call). [The master of a function result is defined by 3.10.2(10/2). Note that if the function call is a master, these two masters will be different.] [RLB: Not sure where to put this. It really belongs in 7.6.1(3/2), but that seems really nasty because how complex the wording there is. We also could put it into 6.4.1, after (15) [and the new rule given below] as a "Notwithstanding" rule, but that isn't very pleasant, either.] Add a new Legality Rule after 6.4.1(6): In a function call, the accessibility level of the actual object for each immutably returnable parameter shall not be statically deeper than accessibility level of the master of the function result. AARM Discussion: Since immutably returnable parameters are always composite, there is always an object (possibly anonymous) to talk about. This is discussing the static accessibility level of the actual object; it does not depend on any runtime information (for instance when the actual object is a formal parameter to another call). Add a new Dynamic Semantics after 6.4.1(15): (this would be a new, outer level, bullet) In a function call, for each runtime returnable parameter, a check is made that the master of the accessibility level of the actual object is the same as or includes the master of the function result. AARM To Be Honest: We're talking about the "nominal" level of the actual object. If the actual object is a formal parameter of some subprogram call C, we do not intend to require dynamic checks that depend on the master of the actual parameters to C, as that would cause nasty distributed overhead (all composite parameters would have to carry accessibility levels). The accessibility level of a formal immutably returnable parameter in a function is that that the return object will have after a return statement completes normally. [That level is defined by 3.10.2(10.1/2). We're talking about inside of the function body. This rule would go somewhere in 3.10.2(6-16), I'm not certain where.]. [This level needs to be defined statically as it is used in legality rules. That prevents using the runtime version for this rule, and that means that parameters of untagged private types are not going to be able to use this accessibility. That does not appear to be a problem, as such parameters do not have any visible aliased parts to return -- discriminants are not aliased; the type is private, so it doesn't have any components, and the parameter itself is not considered aliased. - RLB] [The intent is that this level means that the checks defined in 6.5 for return statements will always succeed (or fail) without any need for any runtime garbage. But this depends on what we end up doing for AI-51; this works best with the fully dynamic version of that AI. If we use Bob's version, then we will have to make a hole in the rules to allow this scenario. One way to do that would be use immutably limited results only, in that case, the other rules given above would be changed similarly. - RLB] Add the following to each Ada.Containers package immediately after Update_Element (with suitable substitutions for the names of types) [note that the names of the type, discriminant, and function are TBD]. type Accessor_Type (Element : not null access Element_Type) is tagged limited private; Accessor_Type needs finalization. A default-initialized object of type Accessor_Type propagates Program_Error. AARM Reason: It is expected that Accessor_Type will be a controlled type, for which finalization will have some action to terminate the tampering check for the associated container. If the object is created by default, however, there is no associated container. Since this is useless, and supporting this case would take extra work, we define it to raise an exception. function Accessor (Container : in out Vector; Position : in Cursor) return Accessor_Type; If Position equals No_Element, then Constraint_Error is propagated; if Position does not designate an element in Container, then Program_Error is propagated. Otherwise, Accessor returns an object whose discriminant is an access to the element designated by Position. Program_Error is propagated if any operation tampers with the elements of Container while the object returned by Accessor exists and has not been finalized. The element designated by Position is not an empty element after successful completion of this operation. [This is only needed for the Vectors case. - ED] Add the following to Ada.Containers.Vectors and its relatives. function Accessor (Container : in out Vector; Index : in Index_Type) return Accessor_Type; If Index is not in the range First_Index (Container) .. Last_Index (Container), then Constraint_Error is propagated. Otherwise, Accessor returns an object whose discriminant is an access to the element at position Index. Program_Error is propagated if any operation tampers with the elements of Container while the object returned by Accessor exists and has not been finalized. The element designated by Position is not an empty element after successful completion of this operation. Add the following to the Erroneous Execution section of each container package: Execution is erroneous if the vector associated with the result of a call to Accessor is finalized before the result object returned by Accessor is finalized. AARM Reason: Each object of Accessor_Type probably contains some reference to the originating container. If that container is prematurely finalized (only possible via Unchecked_Deallocation, as accessibility checks prevent passing a container to Accessor that will not live as long as the result), the finalization of the object of Accessor_Type will try to access a non-existent object. This is a normal case of a dangling pointer created by Unchecked_Deallocation; we have to explicitly mention it here as the pointer in question is not visible in the specification of the type. (This is the same reason we have to say this for invalid cursors.) [Q: Should we add the read-only accessors? They would look like: type RO_Accessor_Type (Element : not null access constant Element_Type) is tagged limited private; function RO_Accessor (Position : in Cursor) return RO_Accessor_Type; function RO_Accessor (Container : in Vector; Index : in Index_Type) return RO_Accessor_Type; The names of all of these functions need work.] !discussion The idea is that the accessibility level of "returnable" parameters of functions is defined such that returning a part (or all) of the parameter as an anonymous access result or as an access discriminant will always succeed. That means no checks (and associated failures) need to be done within the function; we make any needed checks at the call-site instead. The call-site checks can fail only in obscure cases, as the vast majority of objects that could be passed to a function call will outlive the function result. However, if the function result is built-in-place, the result could be made library-level simply by including a call in an allocator for a library level access type. In that case, we do not want to be returning an access to a local object. The check is normally a static one, and imposes overhead only in rare cases (such as passing a dereference of an anonymous access parameter). The checks are (mostly) defined dynamically so that they don't break privacy. We want these rules to apply to all appropriate functions whose full definitions have the appropriate characteristics, but we don't want legality rules depending on the contents of private parts. That would cause generic contract problems, as well. For instance, the properties of the return type are not part of mode-conformance. It would not be possible in a generic body to tell if the rule applied to a particular function or not: generic type Cont is private; type Lim (<>) is limited private; with function Accessor (C : in out Cont) return Lim; package G is procedure Something; end G; package body G is type ALim is access Lim; procedure Something is C : Cont; A : ALim; begin A := new Lim'(Accessor (C)); end Something; end G; package Inst1 is new G (MV.Vector, MV.Accessor_Type, MV.Accessor); -- Better be illegal in the body. package Inst2 is new G (Natural, Natural, Some_Func); -- Body is OK. We could try to apply an assume-the-worst rule, but that essentially turns into the original rule with no conditionality. So the complication doesn't buy much, and it would be a nightmare to implement in a shared generic. By making all of the call checks dynamic in cases like this, we avoid the contract problems. --- Note that the accessibility of the returned object from a call to Accessor will prevent converting the returned access discriminant to any type that lives longer than the returned object. That means that we can assume that the discriminant value cannot be accessed after the object disappears. It is possible to use Unchecked_Deallocation to destroy the returned Accessor_Type object prematurely, while continuing to use the returned access. The accessibility check on the container argument to the Accessor function means that the returned access can't live longer than the container, but the use of Unchecked_Deallocation would allow tampering on the container. This could look like: declare type AT is access MV.Accessor_Type; procedure Free is new Ada.Unchecked_Deallocation (MV.Accessor_Type, AT); PAT : AT := new MV.Accessor_Type'(Vect.Accessor (1)) Element : access Element_Type := PAT.Element; -- OK. begin Free (PAT); -- Tampering checking ends here! Vect.Delete (1); -- No check here. ... Element ... -- Oops, gone. end; Obviously, this is highly unlikely to happen by accident. This is more like shooting oneself in the foot by attaching a laser target to your foot and then firing a laser-seeking missile. It doesn't seem worth worrying about someone who wants to go to these lengths to avoid a tampering check - they're just as likely to use Unchecked_Conversion or .all'Unchecked_Access or something else nasty. --- We don't want to make this change for all parameters of function for compatibility reasons. First, the accessibility checks needed could cause some functions used to initialize an allocator to become illegal or raise Program_Error. While that is relatively rare, it still would be hard to work around. Second, changing the master of all parameters of functions would make function parameters live a long time in some cases (such as when the result is renamed or part of an allocator). That could be especially nasty if the parameter is an object that contains tasks that otherwise would have been terminated or releases locks when finalized. This would be the worst sort of incompatibility, where the program still works but does something different. --- We need to be able to define the period of existence of the return object of the accessor as a time when tampering with elements is prohibited. If we didn't do this, we would be opening the door to all manner of problems (up to and including erroneousness) if an element is added or deleted to the container. To see how this could happen, consider the following example: Assume that Ada.Containers.Vectors has an accessor function defined as follows: function Accessor (C : in out Vector; I : Index_Type) return access Element_Type; Now consider the following program fragments: package Data is type Node (D : Boolean := True) is record case D is when True => CT : Natural; when False => CF : Float; end case; end record; subtype True_Node is Node (D => True); subtype False_Node is Node (D => False); package Node_Vector is new Ada.Containers.Vectors (Element_Type => Node, Index_Type => Positive); Node_List : Node_Vector.Vector; end Data; with Data; package Far_Away is procedure Some_Complex_Operation (...); end Far_Away; package body Far_Away is procedure Some_Complex_Operation (...) is Some_Index : Positive; begin ... Some_Index := ; ... Data.Node_List.Delete (Some_Index); ... end Some_Complex_Operation; end Far_Away; with Data; package Process is procedure Process_True (NT : in out Data.True_Node); end Process; with Far_Away; package body Process is procedure Process_True (NT : in out Data.True_Node) is Component : renames NT.CT; -- OK, NT is constrained. begin ... Far_Away.Some_Complex_Operation (...); if Component > 10 then -- ** Oh-oh!! Component has moved. ... end if; end Process_True; end Process; with Data, Process; procedure Main is begin Data.Node_List.Append (New_Item => (D => False, CF => 1.0)); -- Element 1. Data.Node_List.Append (New_Item => (D => True, CT => 4)); -- Element 2. Data.Node_List.Append (New_Item => (D => False, CF => 26.5)); -- Element 3. ... Process.Process_True (Data.Node_List.Accessor (2).all); ... end Main; Now, in the canonical implementation for a vector, all of the data is stored in an array of some size, and when a component is deleted, the rest of them slide down. So, when the Far_Away operation (probably called through many levels of calls) deletes the first element of the vector, all of the rest of them move. That means that the second element passed to Process_True unexpectedly changes its value to that which was in the third element. But that element doesn't match the constraint and doesn't even have a CT component! So we get erroneous behavior. Note that the same thing would happen if an element was inserted at the front of the vector. Note that in this example no one has copied the access value returned by the accessor. So a rule preventing copying does no good. You can also get a similar effect by renaming the access value itself and doing bad things while the renames exists. Note that the erroneousness can't happen if you use Update_Element instead, because the tampering check will cause the deletion to raise Program_Error. Similarly, cursors have rules allowing implementations to detect this sliding and raise Program_Error. This example code seems plausible; the record type is similar to many found in the author's compiler and using a library-level container is not unusual. So it seems reasonable that cases like this would happen in practice. Thus we conclude that a tampering check is needed for the accessor functions. --- Alternatives: We could define functions to have returnable parameters only for immutably limited result types. That's all we need for the containers, and it would reduce the cases where incompatibilities could arise. But it seems to be preventing the use of a useful tool. We defined a returnable parameter as any that has a "really" composite type and is in a function with an appropriate return type. We could limit these parameters further only to cases that have a part that could be usefully returned: a tagged type (which is implicitly aliased), a type with an aliased part, or parts with access discriminants. We didn't do this as it would cause a maintenance hazard: adding "aliased" to a component in a private type could cause existing function calls that use that type (possibly far away) to start raising Program_Error. A similar issue would happen if a component with an access discriminant were added. Note that this hazard exists somewhat for functions if the return type is changed. This is likely to be fairly rare. It could be mitigated by requiring returning a type with a *visible* access discriminant before the function would be considered as having returnable parameters. That's all we need to use to implement the container's accessors. But it seems restrictive. Another option that was considered was to have a method to mark subprogram parameters that need this capability. As this compatibility is an important part of the profile that ought to figure into mode conformance, this would need to be done with syntax (having a pragma affect legality is uncomfortable). This would have the advantage of applying the accessibility check only to parameters that actually need it, improving flexibility. But adding syntax for a rarely-used case is annoying at best: function Accessor (Container : in out Vector use for return; Position : in Cursor) return Accessor_Type; function Read_Only (Container : Vector use for return; Index : Index_Type) return RO_Accessor_Type; The idea is that "use for return" would be a "mode-modifier", which would be considered as part of profile for conformance purposes. Thus it would have to be included in renames and for generic matching. That neatly gets rid of generic contract issues and all compatibility issues, but of course at the cost of extra syntax. !examples The new Accessor function could be used (based on a recent example from comp.lang.ada): with Ada.Containers.Vectors; procedure Check is package Integer_Vectors is new Ada.Containers.Vectors (Index_Type => Natural, Element_Type => Integer); package Nested_Vectors is new Ada.Containers.Vectors (Index_Type => Natural, Element_Type => Integer_Vectors.Vector, "=" => Integer_Vectors."="); IV : Integer_Vectors.Vector; NV : Nested_Vectors.Vector; begin IV.Append(42); NV.Append(IV); NV.Accessor(0).Element.Append(43); end Check; The dereference does not need to be explicitly given in this case, and the fact that the object returned by Accessor is limited and (probably) controlled is not visible in the code. You could also save the entire object as long as needed: declare My_IV : Nested_Vectors.Accessor_Type := NV.Accessor(0); begin (since My_NV would be built-in-place). Note that this design still works as intended even if the user renames only the limited access value: declare My_IV : Integer_Vectors.Vector renames NV.Accessor(0).Element.all; begin Even in this case, the wrapping finalizable object still is protecting the container, because the master of the returned object is the master of the renames: it will stick around as long as the renames does. Moreover, splitting the access from the object usually isn't possible: declare My_IV : access Integer_Vectors.Vector := NV.Accessor(0).Element; -- Illegal! begin This is illegal because the accessibility check fails. The (anonymous) object returned here will have the master of the expression, which is shorter than the master of the declaration of My_IV. Thus the accessibility check preventing shorter lifetimes will fail. It is OK to rename the access: declare My_IV : access Integer_Vectors.Vector renames NV.Accessor(0).Element; begin as in this case, the anonymous object will continue to exist until the renames is finalized. This element can be passed as a parameter, as again the wrapping object will live as long as the parameter: Operate (NV.Accessor(0).Element); or Munge (NV.Accessor(0).Element.all); !ACATS test ACATS tests would be needed for this feature. !appendix From: Steve Baird Sent: Friday, April 10, 2009 11:12 AM > I think adding "call-level" accessibility is a smaller change, and is > relatively intuitive, so I would rather do that than add a whole > "limited access type" concept. I spoke with Randy yesterday and I believe that we both agree with you on this point. At the risk of repeating much that has been said before, I'll summarize where I think we stand now. As you pointed out, no language changes are needed in order to get the desired functionality in the case where the implementation of the container already uses a level of indirection. This is accomplished by using a function whose result type is tagged limited private with a visible access-to-element discriminant and with a finalization routine that updates the tampering state of the container. Two language changes are needed in the case where the objects that need to be referenced (as variables) in the function result have the accessibility level of the container parameter (as opposed to the accessibility level of the container generic instance, as would typically be the case if a level of indirection is introduced): - in out parameters for functions - a new parameter accessibility rule which has the effect of allowing an immutably limited function result to contain references to (some) parameters; finalization of any referenced actual parameter objects must be correspondingly deferred until after the finalization of the function result object. Both of these are needed in order to support something like type Element_Handle (Element_Ref : access Element) is tagged limited private; function F (C : in out Container; I : Index) return Element_Handle is begin return (Element_Ref => C.Elements(I)'Access, ...); -- result also includes reference -- to C or perhaps C.Tampering_State end F; In whatever cases we decide this new accessibility rule applies, this means that the finalization of the actual parameter may occur later than it otherwise would in the case where the actual parameter is a function call, an aggregate, or an allocator of an anonymous access type. Is this compatibility issue a major concern? **************************************************************** From: Tucker Taft Sent: Friday, April 10, 2009 11:55 AM > Is this compatibility issue a major concern? Not to me. Since I think the result type will inevitably need to be a build-in-place type, these didn't exist before Ada 2005, so the compatibility issues are trivial at this point. Note that I have proposed that access results have essentially the same rules as the access discriminants of build-in-place results, so this would allow for un-wrapped access results to be used in those situations where no finalization is required, accomplishing essentially everything we would get from limited access types. **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 1:09 PM ... > Note that I have proposed that access results have essentially the > same rules as the access discriminants of build-in-place results, so > this would allow for un-wrapped access results to be used in those > situations where no finalization is required, accomplishing > essentially everything we would get from limited access types. This is not true, in that you have no control over the accessibility of the result. The rules you proposed were that the accessibility of the result was that of the type that the access result is converted to. That's not necessarily the same as the place of the call. In the built-in-place object case, you can *only* get the accessibility of the call. That means that an implementation change in a package could cause functions that previously worked to raise Program_Error. This is clearly a maintenance hazard. To take an example, for a library level container C and access type Acc and the following function Func: function Func (C : in out Container) return access Element_Type; declare Ptr : Acc := Func (C); -- (1) begin This call will work if the container is implemented with nodes allocated out of a library-level heap (as is the case with the Unbounded containers), and will raise Program_Error if the container is implemented with an internal array of nodes directly as part of the object (as is the case with the Bounded containers). This means that if the implementation of the container changes, calls might start raising Program_Error for no apparent reason. OTOH, the access discriminant case: declare Ptr : Acc := Func (C).Element; begin will statically fail an accessibilty check (as the discriminanted object has a nested scope, and the access type's is library level). Of course, we're not going to use the former form, so this doesn't matter for Ada.Containers. **************************************************************** From: Tucker Taft Sent: Friday, April 10, 2009 1:39 PM ... > This is not true, in that you have no control over the accessibility > of the result. The rules you proposed were that the accessibility of > the result was that of the type that the access result is converted > to. That's not necessarily the same as the place of the call. In the > built-in-place object case, you can *only* get the accessibility of the call. I don't agree with this. You can use a call on a build-result-in-place function to initialize an allocator of a named access type, and you can return it from an outer build-result-in-place function. In both of these cases, you don't have call accessibility. In general, the caller must indicate whether the context corresponds to "call-level" accessibility or something longer-lasting. On function return, if the function returns 'Access of some part of an actual parameter, then it will have to raise Program_Error if the caller context indicates something longer lasting that call-level accessibility. I believe this is exactly analogous to the case with access results. If you dereference the access result directly, (perhaps to define a rename), you have call-level accessibility. If you convert it to some named type, you don't have call-level accessibility. Similarly, if you use a call of a build-result-in-place function to initialize an allocator for a named access type, then you don't have call-level accessibility. If you pass it to another function, then you do. ... > OTOH, the access discriminant case: > > declare > Ptr : Acc := Func (C).Element; > begin > > will statically fail an accessibilty check (as the discriminanted > object has a nested scope, and the access type's is library level). But what about: declare Ptr : Acc_T := new T'(Func(C)); begin This will have the same issue as the access result. I really believe they are analogous, with similar accessibility rules, if you map "used to initialize allocator of named access type" in the build-in-place case to "converted to named access type" in the access result case. > Of course, we're not going to use the former form, so this doesn't > matter for Ada.Containers. I think you have the same issue using a build-in-place result, but I agree that using it to initialize an allocator of a named access type is perhaps less likely in practice than simply converting an access result to a named access type. The key point in my mind is that the language rules are analogous, so presumably similar implementation techniques can be used, and the user can shift between returning an access result and returning a build-in-place object without huge shifts in capability creating annoying false incentives. **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 2:05 PM ... > I don't agree with this. You can use a call on a > build-result-in-place function to initialize an allocator of a named > access type, and you can return it from an outer build-result-in-place > function. In both of these cases, you don't have call accessibility. I don't see this, although that may be because I've already abandoned the entire idea of call-level accessibility (we don't need it). I'll be making a full(er) write-up right after lunch and you will see. My model is that in all cases, the accessibility of the call is that of the function result. That means in the case of an allocator the master of the call is the master of the access type. So things had better be long-lived. In any case, the "outer built-in-place" function case had better work without raising any funny exceptions. It makes perfect sense to nest these guys (in the container-of-containers case), and I consider that a critical requirement. > In general, the caller must > indicate whether the context corresponds to "call-level" > accessibility or something longer-lasting. There is nothing longer-lasting here; we're just talking about the accessibility of the function result. Period. (The more general notion of call-level accessibility is now dropped, we don't need it.) > On function return, if the function returns 'Access of some part of an > actual parameter, then it will have to raise Program_Error if the > caller context indicates something longer lasting that call-level > accessibility. No. I do think this shows that there may be a need to do an accessibility check *on the parameter* in a few unusual cases. But that check can usually be done statically, so it is a big improvement over the normal case. > I believe this is exactly analogous to the case with access results. > If you dereference the access result directly, (perhaps to define a > rename), you have call-level accessibility. > If you convert it to some named type, you don't have call-level > accessibility. Similarly, if you use a call of a > build-result-in-place function to initialize an allocator for a named > access type, then you don't have call-level accessibility. If you > pass it to another function, then you do. None of this makes any sense to me. We obviously have a different idea of the accessibility rules here. ... > But what about: > > declare > Ptr : Acc_T := new T'(Func(C)); > begin > > This will have the same issue as the access result. Not unless C is a local object. The accessibility of the function result in this case is library level. That's the master of the formal parameter as well. Since that is the case, I think there would have to be an accessibility check on the parameter (so that *it* cannot be a more local than the function result). .. > I think you have the same issue using a build-in-place result, but I > agree that using it to initialize an allocator of a named access type > is perhaps less likely in practice than simply converting an access > result to a named access type. The key point in my mind is that the > language rules are analogous, so presumably similar implementation > techniques can be used, and the user can shift between returning an > access result and returning a build-in-place object without huge > shifts in capability creating annoying false incentives. I agree with this, in that the same rules of accessibility should apply in both cases. We just don't have quite the same idea of the accessibility rules needed. But raising Program_Error conditionally depending on the implementation of the containers is clearly unacceptable. If the accessibility is wrong, that should *always* be detected (even if the actual implementation would allow it to work). I think that the rules I have in mind would have that effect for the containers (yours definitely do not). **************************************************************** From: Tucker Taft Sent: Friday, April 10, 2009 3:35 PM ... > My model is that in all cases, the accessibility of the call is that > of the function result. That means in the case of an allocator the > master of the call is the master of the access type. So things had better be long-lived. You will have to define what you mean by "accessibility of the call." I am guessing this becomes a level that some or all of the actual parameters are being checked against. Perhaps the checks would apply only to those parameters that will have some aliased part or coextension that might be designated by some access value buried in the result object? This sounds hard to specify. The existing Ada 2005 rules for build-in-place clearly have the context of the call determining where the return object is created, be it in the heap, as a component of another object, in a declared variable, or as a temp passed to another subprogram. I presume you aren't planning on changing that. Instead it sounds like you are going to specify that (some or all?) of the (by-reference?) parameters must live at least as long at the return object. ... >> I believe this is exactly analogous to the case with access results. >> If you dereference the access result directly, (perhaps to define a >> rename), you have call-level accessibility. >> If you convert it to some named type, you don't have call-level >> accessibility. Similarly, if you use a call of a >> build-result-in-place function to initialize an allocator for a named >> access type, then you don't have call-level accessibility. If you >> pass it to another function, then you do. > > None of this makes any sense to me. We obviously have a different idea > of the accessibility rules here. I think the difference is that I was presuming no restrictions were being imposed at the call site on the parameters, whereas you are now proposing that there might be some accessibility checks on the parameters. That certainly sounds like an approach worth considering. But everything I wrote earlier has presumed no such checks, so all of the checking had to be performed at the return statement, potentially using information passed in from the caller. I'm not saying that is better, but it might explain the difference in perspective. > > ... >> But what about: >> >> declare >> Ptr : Acc_T := new T'(Func(C)); >> begin >> >> This will have the same issue as the access result. > > Not unless C is a local object. The accessibility of the function > result in this case is library level. That's the master of the formal > parameter as well. Since that is the case, I think there would have to > be an accessibility check on the parameter (so that *it* cannot be a > more local than the function result). Yes, I am beginning to understand your model. It basically assumes the worst about what might be used with 'Access in the return statement. > .. >> I think you have the same issue using a build-in-place result, but I >> agree that using it to initialize an allocator of a named access type >> is perhaps less likely in practice than simply converting an access >> result to a named access type. The key point in my mind is that the >> language rules are analogous, so presumably similar implementation >> techniques can be used, and the user can shift between returning an >> access result and returning a build-in-place object without huge >> shifts in capability creating annoying false incentives. > > I agree with this, in that the same rules of accessibility should > apply in both cases. We just don't have quite the same idea of the > accessibility rules needed. But raising Program_Error conditionally > depending on the implementation of the containers is clearly > unacceptable. If the accessibility is wrong, that should *always* be > detected (even if the actual implementation would allow it to work). I > think that the rules I have in mind would have that effect for the containers (yours definitely do not). I think we aren't that far off, really. If we can agree that access results should piggy-back on the rules for access discriminants of build-in-place return objects, I'm happy. If we decide to impose some accessibility checks on the actual parameters when calling a build-in-place function, those same checks would be relevant for a function with an access result. In either case, the delicate part will be defining which actual parameters are to be checked, and that will in turn imply which formal parameters can be referenced with 'Access in the return statement. **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 10:06 PM Find attached a full write-up of the latest ideas on this topic. [This is /01 of this AI - ED] I'm not completely certain that the accessibility check is harmless in the case of functions that don't need it, but the only way to get rid of it is to add a bit of syntax to differentiate between parameters that need it and those that don't. (See the very end of the !discussion section.) That seems like overkill in the absence of a real problem. Tell me what you think. **************************************************************** From: Tucker Taft Sent: Sunday, April 26, 2009 10:56 PM [Tucker was responding to an earlier draft of version /02 of this AI.] I think what you have proposed is reasonable. I would suggest some changes or perhaps simply a different way of looking at the same essential rules: * Make the access discriminants of the Accessor_Types null excluding. * I don't see the need to say that the finalization of an Accessor_Type has no effect. I think that is just misleading, especially right after we say that it "needs finalization." We don't normally define exactly what an implementation must do to finalize a type appearing in a language-defined package. We merely impose certain requirements (such as no loss of storage) which then imply what needs to occur upon finalization. * If a function call has a result type that, in the caller's view, is anonymous access, classwide, or has a part with an access discriminant ("function call whose result might reference a parameter"), then *all* actual parameters that in the caller's view are tagged, have aliased subcomponents, or have parts with access discriminants ("actual parameters that are referenceable in caller's view"), should be subject to static accessibility checks as part of a legality rule. * If a function call has a result type that, in any view, is anonymous access, classwide, controlling as part of a dispatching call, or has a part with an access discriminant, then *all* actual parameters that are tagged, have aliased subcomponents, or parts with access discriminants in any view, are subject to dynamic accessibility checks prior to the call. (Or, rewording using the phrases used above: If in any view a function call has a result that might reference a parameter, then all actual parameters that are referenceable (in any view) are subject to a dynamic accessibility check before the call.) If a referenceable parameter is a "new" object (aggregate or function call), then its master is that of the function call's return object. If such a call has an actual parameter that is an anonymous allocator, then its master is that of the function call's return object also (I think this partially addresses concerns about the local scope of anonymous allocators). If the call's return object is used to initialize an allocator, and that object is later unchecked-deallocated, then the implementation may at that time also finalize and deallocate these "new" objects associated with the call (including anonymous allocators). I think we are largely in agreement, and this may be just my attempt to reexpress your suggested rules so that I understand them better. **************************************************************** From: Randy Brukardt Sent: Monday, April 27, 2009 11:31 PM ... > * I don't see the need to say that the finalization > of an Accessor_Type has no effect. I think that is > just misleading, especially right after we say that it > "needs finalization." We don't normally define exactly what > an implementation must do to finalize a type appearing > in a language-defined package. We merely impose certain > requirements (such as no loss of storage) which then > imply what needs to occur upon finalization. Understood, but this is a bit of a weird case. All of the wording discusses what happens for values that are returned from one of the Accessor functions. We need to say *something* about the default-initialized case (that is, if one is defined explicitly). In particular, it *must not* have any effect on the tampering state of some container. Perhaps an AARM Implementation note is enough. An alternative would be to have a default-initialized object of this type raise an exception, since it is a useless construct and represents some sort of mistake. That would simplify implementation a bit. I think I'll write it up that way, as it addresses your objection. > * If a function call has a result type that, in the caller's view, > is anonymous access, classwide, or has a part with an access discriminant > ("function call whose result might reference a parameter"), then > *all* actual parameters that in the caller's view are tagged, have > aliased subcomponents, or have parts with access discriminants > ("actual parameters that are referenceable in caller's view"), > should be subject to static accessibility checks as part of a > legality rule. I don't understand the reason for including "classwide" in the result types here. That seems like a significant incompatibility with existing code (and even Ada 95 code). And you can't dispatch to a routine that has such a requirement unless the access discriminant part is known. So it doesn't seem like anything could be done with this. As far as the parameters go, I just applied it to any "really" composite parameter, because anything more specific is a maintenance hazard. With the rule you have, adding a aliased component to a private type might cause far away calls on some unrelated functions that happen to have a parameter of the type to start raising Program_Error. Yuck. > If such a call has an actual parameter that > is an anonymous allocator, then its master is that of the function > call's return object also (I think this partially addresses > concerns about the local scope of anonymous allocators). > If the call's return object is used to initialize an allocator, and > that object is later unchecked-deallocated, then the implementation may > at that time also finalize and deallocate these "new" objects > associated with the call (including anonymous allocators). That sounds worse than co-extensions. This level of complexity would kill the proposal, and it has nothing whatsoever to do with the problem at hand. **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM **************************************************************** From: Randy Brukardt Sent: Friday, April 10, 2009 6:40 PM ****************************************************************