Version 1.4 of ai05s/ai05-0142-4.txt

Unformatted version of ai05s/ai05-0142-4.txt version 1.4
Other versions for file ai05s/ai05-0142-4.txt

!standard 3.10(9/2)          09-06-25 AI05-0142-4/04
!standard 3.10.2(13.1/2)
!standard 6.1(15/2)
!standard 6.1(23)
!standard 6.2(3)
!standard 6.2(10)
!standard 6.3.1(16/2)
!standard 6.4.1(6)
!standard 6.4.1(15)
!standard 7.6.1(13/3)
!class Amendment 09-05-17
!status work item 09-05-17
!status received 09-05-17
!priority Medium
!difficulty Medium
!subject Explicitly aliased parameters and 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. 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 that designates the element type. That 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
Add explicitly aliased parameters, which allow 'Access of parts to be returned as access discriminants and anonymous access returns.
!wording
Modify the first sentence of 3.10(9/2):
A view of an object is defined to be aliased if it is defined by an object_declaration{, parameter_specification, } or component_definition with the reserved word aliased, or by renaming an aliased view.
Add after 3.10.2(13.1/2):
The accessibility level of an explicitly aliased (see 6.1) formal parameter in a function body is determined by the point of call (which is the same level that the return object ultimately will have).
[That level is defined by 3.10.2(10.1/2).].
[The intent is that this level is such that the checks defined in 6.5 for return statements will always succeed (or fail) without any need for any runtime checks and associated overhead. (See the Language Design Principles below.) This depends on the proposed solution for AI-51; the return object then will have the correct level. - RLB]
Replace 6.1(15/2) by:
parameter_specification ::= defining_identifier_list : [aliased] mode [null_exclusion] subtype_mark [:= default_expression] | defining_identifier_list : access_definition [:= default_expression]
Add after 6.1(23): [Static Semantics]
An explicitly aliased parameter is a formal parameter whose parameter_specification includes the reserved word aliased.
Modify 6.2(3):
A type is a by-copy type if it is an elementary type, or if it is a descendant of a private type whose full type is a by-copy type. A parameter of a by-copy type {that is not explicitly aliased} is passed by copy.
Modify 6.2(10):
A parameter of a by-reference type is passed by reference{, as is an explicitly aliased parameter of any type}. Each value...
Modify 6.3.1(16/2):
Two profiles are mode conformant if they are type-conformant, [and] corresponding parameters have identical modes, {both or neither are explicitly aliased parameters}, and, for access parameters or access result types, the designated subtypes statically match, or the designated profiles are subtype conformant.
Add in 6.4.1 of the AARM:
Language Design Principles For explictly aliased parameters of functions, 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 accessibility checks at the call site that all actual objects of explicitly aliased parameters live as long as the function result; then we can allow them to be returned as access discriminants or anonymous access results, as those have the master of the function result as well.
Add after 6.4.1(6): [Legality Rules]
If the formal parameter is an explicitly aliased parameter, the type of the actual parameter shall be tagged or the actual parameter shall be an aliased view of an object. Further, if the formal parameter subtype F is untagged:
* the subtype F shall statically match the nominal subtype of the actual object; or
* the subtype F shall be unconstrained, discriminated in its full view, and unconstrained in any partial view.
AARM Ramification: Tagged objects (and tagged aggregates for in parameters) do not need to be aliased. This matches the behavior of unaliased formal parameters of tagged types, which allow 'Access to be taken of the formal parameter regardless of the form of the actual parameter.
AARM Reason: We need the subtype check on untagged actual parameters so that the requirements of 'Access are not lost. 'Access makes its checks against the nominal subtype of its prefix, and parameter passing can change that subtype. But we don't want this parameter passing to change the objects that would be allowed as the prefix of 'Access. This is particularly important for arrays, where we don't want to require any additional implementation burden.
In a function call, the accessibility level of the actual object for each explicitly aliased parameter shall not be statically deeper than accessibility level of the master of the function result.
[We could make this rule apply to all calls, since it can only fail for functions that initialize allocators, but that doesn't seem to add anything interesting. Note that we don't change the lifetime of anonymous objects or the accessibility of aliased parameters for procedures, so it would be somewhat weird to have this apply to procedures as well.]
AARM Discussion: Since explicitly aliased parameters are either tagged or required to be objects, 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).
AARM Ramification: This accessibility check (and its dynamic cousin as well) can only fail if the function call is used to directly initialize a built-in-place object with a master different than that enclosing the call. The only place all of those conditions exist is in the initializer of an allocator; in all other cases this check will always pass.
Add a new Dynamic Semantics after 6.4.1(15): (this would be a new, outer level, bullet)
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 the same as or includes that of 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 function call F, we do not intend to require dynamic checks that depend on the master of the actual parameters to F, as that would cause nasty distributed overhead (all tagged and explicitly aliased parameters would have to carry accessibility levels).
[Q: Is there a way to reword this to make the above clear?? Masters are usually a dynamic concept, but here we only want to use the master we know, not the actual master of the underlying object (which could be different).]
Modify 7.6.1(13/3): [This wording was modified by AI05-0066-1]
The master of an object is the master enclosing its creation whose accessibility level (see 3.10.2) is equal to that of the object, except in the case of an anonymous object representing the result of an aggregate or function call. {If such an anonymous object is part of the actual parameter expression for an explicitly aliased parameter of a function call, the master of the object is the innermost master enclosing the evaluation of the aggregate or function call, excluding the aggregate or function call itself. Otherwise, the}[The] master of such an anonymous object is the innermost master enclosing the evaluation of the aggregate or function call, which may be the aggregate or function call itself.
AARM Reason: (Add after the existing ones) The special case for explicitly aliased parameters of functions is needed for the same reason, as access discriminants of the returned object may designate one of these parameters. In that case, we want to lengthen the lifetime of the anonymous objects as long as the possible lifetime of the result.
We don't do a similar change for other kinds of calls, because the extended lifetime of the parameters adds no value, but could consistute a storage leak. For instance, such an anonymous object created by a procedure call in the elaboration part of a package body would have to live until the end of the program, even though it could not be used after the procedure returns (other than via Unchecked_Access). End AARM reason
AARM Ramification: Note that the master given to anonymous objects in explicitly aliased parameters of functions is not necessarily as long as the master of the object being initialized (if the funciton call is used to initialize an allocator, for instance). In that case, the accessibility check on explicitly aliased parameters will necessarily fail if any such anonymous objects exist. This is necessary to avoid requiring the objects to live as long as the access type or the implementation complexity of an implicit coextension.
(Note: The following requires AI05-0143-1 to be approved.) Add the following to each Ada.Containers package immediately after Update_Element (with suitable substitutions for the names of types).
type Constant_Reference_Type (Element : not null access constant Element_Type) is tagged limited private;
type Reference_Type (Element : not null access Element_Type) is tagged limited private;
[Bob recommends just using "E" for the name of the discriminant.]
Constant_Reference_Type and Reference_Type need finalization.
The default initialization of an object of type Constant_Reference_Type or Reference_Type propagates Program_Error.
AARM Reason: It is expected that Reference_Type (and Constant_Reference_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 Constant_Reference (Container : aliased in Vector; Position : in Cursor) return Constant_Reference_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, Constant_Reference returns an object whose discriminant is an access value that designates the element designated by Position. Program_Error is propagated if any operation tampers with the elements of Container while the object returned by Constant_Reference exists and has not been finalized.
function Reference (Container : aliased in out Vector; Position : in Cursor) return Reference_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, Reference returns an object whose discriminant is an access value that designates the element designated by Position. Program_Error is propagated if any operation tampers with the elements of Container while the object returned by Reference 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 Constant_Reference (Container : aliased in Vector; Index : in Index_Type) return Reference_Type;
If Index is not in the range First_Index (Container) .. Last_Index (Container), then Constraint_Error is propagated. Otherwise, Constant_Reference returns an object whose discriminant is an access value that designates the element at position Index. Program_Error is propagated if any operation tampers with the elements of Container while the object returned by Constant_Reference exists and has not been finalized.
function Reference (Container : aliased in out Vector; Index : in Index_Type) return Reference_Type;
If Index is not in the range First_Index (Container) .. Last_Index (Container), then Constraint_Error is propagated. Otherwise, Reference returns an object whose discriminant is an access value that designates the element at position Index. Program_Error is propagated if any operation tampers with the elements of Container while the object returned by Reference 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 Reference or Constant_Reference is finalized before the result object returned by the call to Reference or Constant_Reference is finalized.
AARM Reason: Each object of Reference_Type and Constant_Reference_Type probably contains some reference to the originating container. If that container is prematurely finalized (which is only possible via Unchecked_Deallocation, as accessibility checks prevent passing a container to Reference that will not live as long as the result), the finalization of the object of Reference_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.)
!discussion
The idea is that the accessibility level of explicitly aliased 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.
We include the aliased property of parameters in mode conformance, so that the need (or not) to make accessibility checks is always known at compile-time. This means that it cannot be hidden by renames or generic formal parameters, and most importantly, does not change for dispatching routines. It would be a disaster for a dispatching call to call a function that has aliased parameters without making necessary accessibility checks on those parameters; that would be possible if "aliased" was not part of mode conformance.
---
Note that the accessibility of the returned object from a call to Reference 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 (thus we can tie the tampering check to the lifetime of the returned object).
It is possible to use Unchecked_Deallocation to destroy the returned Reference_Type object prematurely, while continuing to use the returned access. The accessibility check on the container argument to the Reference 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.Reference_Type; procedure Free is new Ada.Unchecked_Deallocation (MV.Reference_Type, at);
PAT : at := new MV.Reference_Type'(Vect.Reference (1))
Element : access Element_Type := PAT.Element; -- OK.
begin Free (PAT); -- Tampering checking ends here!
Vect.Delete (1); -- No check here. ... Element.all ... -- 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 treat all parameters of functions like explicitly aliased parameters for compatibility and wording reasons.
We don't want to have to define accessibility checks on values, and we proved that trying to tie this property to particular types causes maintenance hazards (see the earlier alternative AI05-0142-3 to see why).
In addition, 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.
Finally, changing the master of all anonymous objects in 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.
---
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 designating 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).
For example:
package Test is type Rec (A : access Integer) is null record; -- Build-in-place type.
type A_Rec is access Rec;
Root : A_Rec;
function Constructor (Param : aliased in out Integer) return Rec is begin return (A => Param'access); end Constructor;
procedure Do_It is My_Value : aliased Integer := 10; begin Root := new Rec'(Constructor (My_Value)); -- Illegal. end Do_It;
begin Do_It; if Root.A = 10 then -- A doesn't exist anymore. ... end if; end Test;
Since Rec is built-in-place, its access discriminants have the master of the access type A_Rec. That lives longer than the parameter My_Value, which is used as the access discriminant. Thus we have to make something illegal somewhere. We chose to make an accessibility check at the call site, as this do not usually require the overhead of dynamic checks.
---
We briefly considered and rejected allowing explicitly aliased function results. Such returns would need to work as-if they are returned by reference.
We could allow aliased results when a function call is used directly as the actual for an explicitly aliased parameter. We already do allow that a function that returns a tagged type (since these are always considered aliased), and most likely we could allow something similar for untagged types.
But other uses would require the result to be built in place to get the effect of a reference return. We don't want to require build-in-place semantics for non-limited types, as that is not safe when assigning into existing objects, and we don't want to add to the implementation burden.
---
The legality rule that requires static matching for untagged subtypes is required in order to prevent problems with the parameter passing changing the nominal constraint of the object. If 'Access is taken later, it might be legal when otherwise taking 'Access of that object directly would have been illegal.
For instance:
type vector is array (positive range <>) of Natural;
Actual : aliased vector (1 .. 4); -- Nominal subtype is constrained
function Has_Four_Elements (x : aliased in vector) return Boolean is type Ref is access constant vector; Ptr : Ref; begin if X'First > 1 then Ptr := Actual'access; -- (1) return Ptr.all'Length = 4; else Ptr := X'access; -- (2) return Ptr.all'Length = 4; end if; end Has_Four_Elements;
Has_Four : constant Boolean := Has_Four_Elements (Actual);
(1) is illegal because the subtypes don't statically match. However, (2) is legal because the nominal subtype of X does statically match the designated type of Ref, Vector. We don't want incentives to pass something as a parameter so it can be used where it would not be able to be used directly.
Note that this check in the array case is primarily about implementations being able to continue to require a contiguous representation of array dope. If the compiler does not assume that contiguous representation, it would be simple to implement this case by creating the needed dope at the point of the function call. Unlike the normal case of 'Access (where the needed lifetime of the dope is unclear, making a likely storage leak, even if non-continguous representations are supported), here the dope only needs to exist as long as the function result does - the same lifetime as any other temporary created as part of the evaluation of the actual of an explicitly aliased parameter.
We also need this check in order to prevent mismatches in scalar subtypes; for instance, we surely do not want to create an access-to-Integer that designates an aliased Natural object.
This rule is annoying as it is reasonable (for a container, for instance) to never actually use 'Access on the entire passed object in the body. An access to some component may be referenced instead. But we think that for typical containers (implemented as private types, either without discriminants or with unconstrained discriminants), a client would never run into this rule. That's because of the exception for unconstrained discriminated types and because a private type without discriminants could not have a constraint that didn't match. The check is most likely to fail for arrays and scalar types, but in these cases it it much more likely that the entire object will be returned.
It has been noted that we could leverage the existing 'Constrained flag to make part of this check at runtime. However, this really does not help very much. We would still have to use static matching if the subtype of the explicitly aliased parameter is constrained. And most other cases are already legal. We could change the 6.4.1(6) wording to:
Further, if the formal parameter subtype F is untagged:
* the subtype F shall statically match the nominal subtype of the actual object; or
* the subtype F shall be unconstrained and discriminated.
But then we would need to add after to 3.10.2(29):
If the designated type D is untagged, discriminated in its full view, and constrained in any partial view, a check is made X'Constrained is False; Program_Error is raised if this check fails.
AARM Notes: This check can only fail if the view is a formal parameter, in all other cases static matching will ensure that it is successful.
This doesn't seem to save much wording nor allow many additional cases.
We could get more bang for our buck by defining another attribute that would work on arrays:
A'Nominally_Constrained
For an explicitly aliased formal parameter F of an array type, returns True if the nominal subtype of the actual object is constrained, and returns False otherwise. For other objects of an array type, returns True if the nominal subtype of the object is constrained, and returns False otherwise.
Then the 6.4.1(6) wording could be changed to: Further, if the formal parameter subtype F is untagged:
* the subtype F shall statically match the nominal subtype of the actual object; or
* the subtype F shall be unconstrained and either discriminated or an array subtype.
We would need to add after to 3.10.2(29) (in addition to the wording above):
If the designated type D is an array type and unconstrained, a check is made X'Nominally_Constrained is False; Program_Error is raised if this check fails.
This would have some additional runtime overhead, but would allow more flexibility for array parameter passing (any sort of array object could be passed to an explicitly aliased unconstrained array parameter).
Note that we could make changes like these in the future; they would be compatible with the current rules (as they would only allow more). So we adopt the more restrictive rule now and we can liberalize it in the future if needed.
---
Given that we had to make a check of 3.10.2(27-27.2/2) to avoid problems, one might wonder why we don't need to make a matching check of 3.10.2(26). Here, however, the existing rules of erroneousness prevent trouble. To see that, consider:
type Rec (B : Boolean := False) is record case B is when True => C1 : aliased Natural; when False => null; end case; end record;
Obj : Rec := (True, C1 => 10);
function A_Func (P : aliased in Natural) return access Natural is begin Obj := (False); -- (1) return P'access; -- (2) end A_Func;
if A_Func.all(Obj.C1) = 10 then null; end if;
The assignment to Obj at (1) changes the discriminant and causes the component Rec.C1 to cease to exist. That's bad because that component has been passed (by reference) as an aliased parameter, and we then use that parameter after the component has gone away.
Luckily, 3.7.2(4) makes execution of A_Func erroneous. Thus we don't need additional checks for this case. (And it would be weird to have them, given that regular parameter passing does not try to prevent this problem.)
---
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 Reference (C : aliased 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 := <lengthy-computation-resulting-in-value-of-1>; ... 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.Reference (2).all); ... end Main;
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.
!examples
The new Reference 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.Reference(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 Reference is limited and (probably) controlled is not visible in the code as the function call is used directly as a prefix.
You could also save the entire object as long as needed:
declare My_IV : Nested_Vectors.Reference_Type := NV.Reference(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 discriminant access value:
declare My_IV : Integer_Vectors.Vector renames NV.Reference(0).Element.all; begin
Even in this case, the wrapping (probably controlled) 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.Reference(0).Element; -- Illegal! begin
This is illegal because the accessibility check fails. The (anonymous) object returned here will have the master of the expression (as a prefix, the special "directly initializing" rule does not apply to this function call), 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.Reference(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.Reference(0).Element);
or
Munge (NV.Reference(0).Element.all);
!ACATS test
ACATS tests would be needed for this feature.
!appendix

From: Tucker Taft
Sent: Sunday, May 17, 2009  11:39 AM

You ask whether "aliased" goes before or after the mode.
My instinct would say before the mode, since "aliased" goes before "constant" in
an aliased constant, and a mode is most like the word "constant" in its effect.
I also think it reads a bit better.

If it does come before, in general, then I would *require* some explicit mode
specifier, rather than making "in" the default.  I.e.:

     [[aliased] mode] [null_exclusion] ...

From a higher level point of view, since "aliased" pretty dramatically affects
the mode (e.g. by changing by-copy to be by-reference) it seems like it belongs
in front of the mode.  That is, you aren't just passing "in" an aliased object,
but you are actually using an "aliased" parameter passing mechanism.

****************************************************************

From: Bob Duff
Sent: Sunday, May 17, 2009  12:35 PM

> You ask whether "aliased" goes before or after the mode.
> My instinct would say before the mode, since "aliased" goes before
> "constant" in an aliased constant, and a mode is most like the word
> "constant" in its effect.  I also think it reads a bit better.

I agree.

> If it does come before, in general, then I would *require* some
> explicit mode specifier, rather than making "in"
> the default.

Why?  What's wrong with "X : aliased T;"?  Why do you prefer to force it to be
"X : aliased in T;"?

>...I.e.:
>
>      [[aliased] mode] [null_exclusion] ...

I don't think this syntax accomplishes your goal, given:

16    mode ::= [in] | in out | out

>  From a higher level point of view, since "aliased" pretty
> dramatically affects the mode (e.g. by changing by-copy to be
> by-reference) it seems like it belongs in front of the mode.  That is,
> you aren't just passing "in" an aliased object, but you are actually
> using an "aliased" parameter passing mechanism.

I agree.

****************************************************************

From: Tucker Taft
Sent: Sunday, May 17, 2009  12:58 PM

> Why?  What's wrong with "X : aliased T;"?  Why do you prefer to force
> it to be "X : aliased in T;"?

It just seems that defaults are only useful if it is self-evident what they
should be.  For aliased formal parameters, a default of "in" seems less
appropriate.  Also, somehow the default in the "middle" (between "aliased" and
the type) seemed a bit weird.  Normally defaults show up at the end, or
conceivably at the front, but in the middle seemed less satisfying.

>
>> ...I.e.:
>>
>>      [[aliased] mode] [null_exclusion] ...
>
> I don't think this syntax accomplishes your goal, given:
>
> 16    mode ::= [in] | in out | out

Good point.  I guess "mode" should not be marked as optional, then.  Perhaps
"aliased" could be part of the mode:

     mode ::= [[aliased] in] | [aliased] in out | [aliased] out

****************************************************************

From: Tucker Taft
Sent: Sunday, May 17, 2009  5:01 PM

> It just seems that defaults are only useful if it is self-evident what
> they should be.  For aliased formal parameters, a default of "in"
> seems less appropriate.  Also, somehow the default in the "middle"
> (between "aliased" and the type) seemed a bit weird.  Normally
> defaults show up at the end, or conceivably at the front, but in the
> middle seemed less satisfying.

OK, thanks for explaining your point of view.  I don't really agree, I mean,
everybody knows "in" is the default, right?  Self-evidently.  ;-)  And if
somebody thinks "aliased" means "aliased in out", they will be disabused of that
notion pretty quickly by the compiler.

But anyway, I don't feel strongly.

> >> ...I.e.:
> >>
> >>      [[aliased] mode] [null_exclusion] ...
> >
> > I don't think this syntax accomplishes your goal, given:
> >
> > 16    mode ::= [in] | in out | out
>
> Good point.  I guess "mode" should not be marked as optional, then.
> Perhaps  "aliased" could be part of the mode:
>
>      mode ::= [[aliased] in] | [aliased] in out | [aliased] out

I don't much like that, because "aliased" is not really part of the mode; this
takes us further from the analogy with "aliased constant".

If we go this way, I'd prefer a syntax rule written in English, "If you say
'aliased', then 'in' must be explicit" or RM-ese to that effect.  Or else
redesign the syntax rules:

    mode ::= in | in out | out

Then change "mode" to "[mode]" in various existing places, and then your
syntax:

   [[aliased] mode] [null_exclusion] ...

works.

Might require a few wording tweaks -- we need to make sure the default mode is
'in' in existing places.

****************************************************************

From: Tucker Taft
Sent: Sunday, May 17, 2009  5:12 PM

I don't feel strongly either, though I do feel more strongly that "aliased"
should come before the mode indicator (if any).

****************************************************************

From: Bob Duff
Sent: Sunday, May 17, 2009  7:14 PM

Yes, I agree with that.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May 19, 2009  3:15 PM

> I don't feel strongly either, though I do feel more strongly that
> "aliased" should come before the mode indicator (if any).

OK, I'll rewrite it that way. I think we should leave the issue about
the default for the full ARG, as it doesn't look like a consensus is
apparent. (And I don't really want a syntax argument to complicate
matters.)

****************************************************************

From: Bob Duff
Sent: Sunday, May 17, 2009  12:32 PM

> Attached find my first attempt at "aliased parameters". It looks
> pretty good, at least until Steve gets a hold of it. Probably some of
> the accessibility wording is convoluted. [This was version /01 - ED.]

Looks very promising.  Good job!

Mostly just editorial comments, below.

> 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.

I'd erase the part starting "to define..." -- doesn't seem to add much.

>... 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.

Not clear what "this" refers to -- the rejection?

>... 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
>
> Add aliased parameters, which allow 'Access of parts to be returned as
> = access discriminants and anonymous access returns.
>
> !wording
>
> Modify the first sentence of 3.10(9/2):
>
> A view of an object is defined to be *aliased* if it is defined by an
> = object_declaration{, parameter_specification, } or
> component_definition with the reserved = word *aliased*, or by
> renaming an aliased view.
>
> Add somewhere in 3.10.2(6-16): [Q: Where??]

Shrug.

> The accessibility level of a formal aliased parameter in a function
> body

                               aliased formal parameter

> is that that the return object will have after a return statement =

"that that" only made sense to me on the third reading. ;-) How about "is the
level the ..."?

> completes
> normally.
>
> [That level is defined by 3.10.2(10.1/2).].
>
> [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. (See the Language Design Principles below.)
> But this depends on =
  "garbage"?

> 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 =

Bob's version is based on the premise that these things are pretty-much useless,
and therefore the rules should simplify implementations above all else.  But if
you've found a way to make them useful, then Bob would probably withdraw his
suggestion.

> 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.
> Another option would be a syntax marker on the return that we want a =
> shorter lifetime for the result. - RLB]
>
>
> Replace 6.1(15/2) by:
>
> parameter_specification ::=3D
>    defining_identifier_list : mode [aliased] [null_exclusion] =
> subtype_mark [:=3D default_expression]  | defining_identifier_list :
> access_definition [:=3D = default_expression]
>
> [Q: Does [aliased] go before or after the mode? I thought it worked =
> better after the mode, as then the types are more like the types in an
> object_declaration. But it = probably doesn't matter.]

I think it matters, and I think "aliased" belongs before the mode.
My reason: Because "then the types are more like the types in an
object_declaration."  ;-)  See Tuck's explanation.

> Add after 6.1(23): [Static Semantics]
>
> An *aliased parameter* is a formal parameter that includes the
> reserved =
                                               ^^^^whose declaration
> word *aliased*.

I suspect we might get in trouble if we use the term "aliased parameter".
Better spell it out, "aliased formal parameter", I think.

Actually, it's worse: tagged formal parameters are aliased, so this term is
fundamentally confusing.

> Modify 6.3.1(16/2):
>
> Two profiles are mode conformant if they are type-conformant, [and] =
> corresponding parameters have identical modes, {both or neither are
> aliased parameters}, and, for =
How about:               both or neither include the reserved word 'aliased',
and, for

> access parameters or
> access result types, the designated subtypes statically match, or the
> = designated profiles are subtype conformant.
>
> Add in 6.4.1 of the AARM:
>
> Language Design Principles
> For aliased parameters of functions, 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 accessibility checks at the call site that all actual
> = objects of aliased parameters live as long as the function result;
> then we can = allow them to be returned as access discriminants or
> anonymous access results, as = those have the master of the function
> result as well.
>
> Add after 6.4.1(6): [Legality Rules]

I don't know if it works everywhere, but if you replace the above definition of
"aliased parameter" with "A formal parameter is 'explicitly aliased' if its
declaration includes the reserved word *aliased*.", then you could say:

> If the formal parameter is an aliased parameter, the type of the
> actual =
                                explicitly aliased
> parameter shall be
> tagged or the actual parameter shall be an aliased view of an object.
>
> AARM Ramification: Tagged objects (and tagged aggregates for *in* =
> parameters) do not need
> to be aliased. This matches the behavior of unaliased formal
> parameters, = which allow 'Access to be taken of any actual parameter.

I don't understand that last phrase.

> In a function call, the accessibility level of the actual object for
> each aliased parameter shall not be statically deeper than
> accessibility level of the master of the function result.
>
> [We could make this rule apply to all calls, since it can only fail
> for = functions that initialize allocators, but that doesn't seem to
> add anything = interesting. Note that we don't change the lifetime of
> anonymous objects or the accessibility of = aliased parameters for
> procedures, so it would be somewhat weird to have this apply to =
> procedures as well.]

Could you remind us why procedures are different?

> AARM Discussion: Since aliased parameters are either tagged or
> required = to be objects, 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).
>
> AARM Ramification: This accessibility check (and its dynamic cousin as
> =
> well) can only fail
> if the function call is used to directly initialize a built-in-place =
> object with a master different than that enclosing the call. The only
> place all of those = conditions exist is in the initializer of an
> allocator; in all other cases this check will = always pass.
>
> Add a new Dynamic Semantics after 6.4.1(15): (this would be a new,
> outer = level, bullet)
>
> In a function call, for each aliased parameter, a check is made that
> the master of the accessibility level of the actual =
Heh? "master of level"?

> object is
> the same as or includes that of 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 function call F, we
> = do not intend to require dynamic checks that depend on the master of
> the actual parameters to F, as that would cause nasty distributed
> overhead (all = tagged and aliased parameters would have to carry
> accessibility levels).
>
>
> Modify 7.6.1(13/3): [This wording was modified by AI05-0066-1]
>
> The master of an object is the master enclosing its creation whose =
> accessibility level (see 3.10.2) is equal to that of the object,
> except in the case of an = anonymous object representing the result of
> an aggregate or function call. {If such an = anonymous object is part
> of the actual parameter expression for an aliased parameter of a =
> function call, the master of the object is the innermost master
> enclosing the = evaluation of the aggregate or function call,
> excluding the aggregate or function call itself. = Otherwise,
> the}[The] master of such an anonymous object is the innermost master
> enclosing the = evaluation of the aggregate or function call, which
> may be the aggregate or function = call itself.
>
> AARM Reason: (Add after the existing ones) The special case for
> aliased parameters of functions is needed for the = same reason, as
> access discriminants of the returned object may designate one of =
> these parameters.
> In that case, we want to lengthen the lifetime of the anonymous
> objects = as long as the possible lifetime of the result.
>
> AARM Ramification:
> Note that the master given to anonymous objects in aliased parameters
> of = functions is not necessarily as long as the master of the object
> being initialized = (if the funciton call is used to initialize an
> allocator, for instance). In that case, = the accessibility check on
> aliased parameters will necessarily fail if any such anonymous =
> objects exist.
> This is necessary to avoid requiring the objects to live as long as
> the = access type or the implementation complexity of an implicit
> coextension.
>
>
> 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;

I'm inclined to make the discriminant name very short, maybe just "E", because
Accessor_Type conceptually _is_ a pointer, so the extra ".Element" is just
noise.  The only reason it exists is for some internal checking inside the
containers package.

> 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 aliased 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 =

"discriminant designates"

> 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 aliased 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 =

"discriminant designates"

> 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?

Probably.

>.. They would look like:
>
>     type RO_Accessor_Type (Element : not null access constant =
> Element_Type) is
>        tagged limited private;
>
>     function RO_Accessor (Position : in aliased Cursor) return =
> RO_Accessor_Type;
>
>     function RO_Accessor (Container : in aliased 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 aliased 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).
>
> We include the aliased property of parameters in mode conformance, so
> = that the need (or not) to make accessibility checks is always known
> at compile-time. This means = that it cannot be hidden by renames or
> generic formal parameters, and most importantly, = does not change for
> dispatching routines. It would be a disaster for a dispatching call to
> = call a function that has aliased parameters without making necessary
> accessibility checks on = those parameters; that would be possible if
> "aliased" was not part of mode conformance.
>
> ---
>
> 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 :=3D new MV.Accessor_Type'(Vect.Accessor (1))
>
>       Element : access Element_Type :=3D 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.

Agreed that we needn't worry about this case.

> ---
>
> We don't want to treat all parameters of functions like aliased =
> parameters for compatibility and wording reasons.
>
> We don't want to have to define accessibility checks on values, and we
> = proved that trying to tie this property to particular types causes
> maintenance hazards (see = the earlier alternative AI05-0142-3 to see
> why).
>
> In addition, 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.
>
> Finally, changing the master of all anonymous objects in 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 aliased Vector; I : Index_Type) return =
> access Element_Type;
>
> Now consider the following program fragments:
>
>   package Data is
>     type Node (D : Boolean :=3D True) is record
>           case D is
>               when True =3D>
>                   CT : Natural;
>               when False =3D>
>                   CF : Float;
>           end case;
>     end record;
>     subtype True_Node  is Node (D =3D> True);
>     subtype False_Node is Node (D =3D> False);
>
>     package Node_Vector is new Ada.Containers.Vectors (Element_Type
> =3D> = Node,
>            Index_Type =3D> 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 :=3D <lengthy-computation-resulting-in-value-of-1>;

:= Ident_Int(1);

>         ...
>         Data.Node_List.Delete (Some_Index);
>         ...
>     end Some_Complex_Operation;
>   end Far_Away;

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May 19, 2009  4:15 PM

...
> > 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.
>
> I'd erase the part starting "to define..." -- doesn't seem to add
> much.

OK.

> >... 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.
>
> Not clear what "this" refers to -- the rejection?

"returning an access to the element type from Ada.Containers". Which is why I
used "this", way too long otherwise. I suppose I could shorten it to "returning
an access"

However, returning an access is problematic as it is difficult to control the
accessibility and lifetime of the returned access.

But maybe the real problem is the "However", since there is no reverse sense
here. Maybe just "That is problematic...".

...
> > Add somewhere in 3.10.2(6-16): [Q: Where??]
>
> Shrug.

That's helpful. ;-)

> > The accessibility level of a formal aliased parameter in a function
> > body
>
>                                aliased formal parameter
>
> > is that that the return object will have after a return statement =
>
> "that that" only made sense to me on the third reading. ;-) How about
> "is the level the ..."?

Sounds good.

> > completes
> > normally.
> >
> > [That level is defined by 3.10.2(10.1/2).].
> >
> > [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. (See the Language Design
> Principles below.)
> > But this depends on =
>   "garbage"?

The problem with late-at-night AI drafting. I was thinking that the code that
executes runtime checks does not progress the application to its final result,
so it is just garbage as far as the final result is concerned. Should just say
"checks", or maybe "checks and associated overhead" (since it is passing the
runtime levels that is the expensive part).

> > 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 =
>
> Bob's version is based on the premise that these things are
> pretty-much useless, and therefore the rules should simplify
> implementations above all else.  But if you've found a way to make
> them useful, then Bob would probably withdraw his suggestion.

Well, it seems to me that in this case, we don't need the full dynamic overhead,
so we probably could do better -- but the problem is we would need different
rules for this case rather than normal ones.

We could even tie it to the presence on explicitly aliased parameters, except
that would have the effect of making other kinds of uses of aliased parameters
hard.

...
> > [Q: Does [aliased] go before or after the mode? I thought it worked
> > = better after the mode, as then the types are more like the types
> > in an object_declaration. But it = probably doesn't matter.]
>
> I think it matters, and I think "aliased" belongs before the mode.
> My reason: Because "then the types are more like the types in an
> object_declaration."  ;-)  See Tuck's explanation.

OK, I've changed this based on the opinion of you and Tucker.

> > Add after 6.1(23): [Static Semantics]
> >
> > An *aliased parameter* is a formal parameter that includes the
> > reserved =
>                                                ^^^^whose declaration
> > word *aliased*.

Humm; formal parameters aren't declarations, so I don't think this wording
works. Besides, the wording for "aliased" entity in 3.10(9) doesn't say anything
about declarations. We could say "formal parameter whose parameter_specification
includes...".

> I suspect we might get in trouble if we use the term "aliased parameter".
> Better spell it out, "aliased formal parameter", I think.
>
> Actually, it's worse: tagged formal parameters are aliased, so this
> term is fundamentally confusing.

I think you are right, and changed it to explicitly aliased parameter
everywhere. Not sure if we need the "parameter", but "explicitly aliased" is
rather broad, it woud be weird if the object declaration
   A : aliased B;
is not "explicitly aliased".

We can revisit this later if its too weird.

...
> > Add after 6.4.1(6): [Legality Rules]
>
> I don't know if it works everywhere, but if you replace the above
> definition of "aliased parameter" with "A formal parameter is
> 'explicitly aliased' if its declaration includes the reserved word
> *aliased*.", then you could say:
>
> > If the formal parameter is an aliased parameter, the type of the
> > actual =
>                                 explicitly aliased
> > parameter shall be
> > tagged or the actual parameter shall be an aliased view of an object.

See above.


> > AARM Ramification: Tagged objects (and tagged aggregates for *in* =
> > parameters) do not need
> > to be aliased. This matches the behavior of unaliased formal
> > parameters, = which allow 'Access to be taken of any actual
> parameter.
>
> I don't understand that last phrase.

"This matches the behavior of unaliased formal parameters {of tagged types},
which allow 'Access to be taken of {the formal parameter regardless of the form
of the}[any] actual parameter."

> > In a function call, the accessibility level of the actual object for
> > each aliased parameter shall not be statically deeper than
> > accessibility level of the master of the function result.
> >
> > [We could make this rule apply to all calls, since it can only fail
> > for = functions that initialize allocators, but that doesn't seem to
> > add anything = interesting. Note that we don't change the lifetime
> > of anonymous objects or the accessibility of = aliased parameters
> > for procedures, so it would be somewhat weird to have this apply to
> > = procedures as well.]
>
> Could you remind us why procedures are different?

Because the extended lifetime of anonymous objects has no benefit for
procedures, but could consistute a storage leak if the objects are large. For
instance, such an anonymous object created by a procedure call in the
elaboration part of a package body would have to live until the end of the
program, even though it could not be used after the procedure returns (other
than via Unchecked_Access). This should be mentioned in the AARM notes under
7.6.1(13/3) [and now is].


> > Add a new Dynamic Semantics after 6.4.1(15): (this would be a new,
> > outer = level, bullet)
> >
> > In a function call, for each aliased parameter, a check is
> made that
> > the master of the accessibility level of the actual =
> Heh? "master of level"?

Just testing your reading comprehension. ;-) I did warn you that some of the
accessibility wording was confused.

...
> > 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;
>
> I'm inclined to make the discriminant name very short, maybe just "E",
> because Accessor_Type conceptually _is_ a pointer, so the extra
> ".Element"
> is just noise.  The only reason it exists is for some internal
> checking inside the containers package.

Well, it's noise no matter what it is named: E, Element, or Gigantic_Muggywump.
Ada usually uses full words, so I used the longer (not joke) name. But I don't
care much, naming always leads to such passion that I don't expect to finalize
it now.

> > Otherwise, Accessor returns an object whose discriminant is
> an access
> > to =
>
> "discriminant designates"

That can't be right, 3.10(1) says that "designates" is something that an access
value does to an object. I don't mind using a better verb here, but one that has
a defined meaning (and surely could be confused here, given that we're talking
about access types) won't do.

We could say "an access that designates the element" (that's better than "to").

...
> >         Some_Index :=3D
> <lengthy-computation-resulting-in-value-of-1>;
>
> := Ident_Int(1);

Only long-time ACATS users are likely to be familiar with the optimization
blocking Ident_Int function. It would take longer to explain it to everyone else
than to just say it as I did.

(We could confuse them even more by calling is Report.Ident_Int. :-)

****************************************************************

From: Tucker Taft
Sent: Sunday, May 17, 2009  1:00 PM

I think somewhere you need to state that aliased parameters are always passed by
reference, whether elementary or composite.

****************************************************************

From: Steve Baird
Sent: Monday, May 18, 2009  11:43 AM

This looks generally very good.

I'd like to see more examples (e.g. illustrating the success/failure cases that
the various static and dynamic rules are intended to distinguish).

I think the same subtype matching checks that are associated with a use of
X'Access need to be performed when X is passed as an actual parameter.

Example #1 -

     type immutably_limited is  ... ; -- contains tasks, etc.

     type vector is array (positive range <>) of immutably_limited;

     function Has_Four_Elements (x : aliased in vector) return Boolean is
         type Ref is access constant vector;
         Ptr : ref := X'access;
     begin
         return Ptr.all'Length = 4;
     end Has_Four_Elements;

     actual : aliased vector (1 .. 4); -- nominal subtype is constrained

     has_Four : constant Boolean := Has_Four_Elements (Actual);

This example should be illegal.

Consider an implementation which uses a contiguous-dope-vector representation to
implement access types where the designated subtype is an unconstrained array
subtype.

Because the nominal subtype of Actual is constrained, no such contiguous dope
vector would be allocated for Actual. Has_Four_Elements would, however, expect
that dope vector to be there.

Example #2-

    I am skeptical about aliased scalar parameters to begin with
    (although I understand the generic contract issues that would
    result if we wanted to disallow them).

    There are similar problems with say, an "aliased in out natural"
    parameter being passed an actual parameter whose subtype is
    either Integer or Positive.

Are there issues with the constrainedness of a discriminated actual/formal
parameter pair?  I need to think about this one.

****************************************************************

From: Tucker Taft
Sent: Monday, May 18, 2009  12:16 PM

I think the rules for 'Access solve most of the problems.  That is, think of it
as though it said "access Natural" rather than "aliased Natural." Ditto for
access-to-discriminated record, which already have well-defined, safe rules.

****************************************************************

From: Steve Baird
Sent: Monday, May 18, 2009  2:01 PM

I agree that this is the right way to think of it.

One might respond to this by saying "if you really meant an anonymous access
parameter, then why didn't you say so? Why are we even talking about a parameter
of the designated type?".

One of the advantages of the "aliased parameter" approach is that it doesn't
allow allocators as actual parameters, which means that we don't have to work
out the finalization/accessibility/storage_pool rules for such a beast.

****************************************************************

From: Tucker Taft
Sent: Monday, May 18, 2009  3:23 PM

It presumably *does* allow tagged aggregates (for aliased "in"), so we aren't
completely off the hook, since they can have coextensions.

****************************************************************

From: Steve Baird
Sent: Monday, May 18, 2009  3:38 PM

You're right.

****************************************************************

From: Bob Duff
Sent: Tuesday, May 19, 2009  5:35 PM

> > > Otherwise, Accessor returns an object whose discriminant is an access
> > > to =
> > 
> > "discriminant designates"
> 
> That can't be right, 3.10(1) says that "designates" is something that 
> an access value does to an object. I don't mind using a better verb 
> here, but one that has a defined meaning (and surely could be confused 
> here, given that we're talking about access types) won't do.
> 
> We could say "an access that designates the element" (that's better 
> than "to").

I don't understand your objection.  It seems like "designates" is exactly
what you want, here.  The discriminant is an access value, and it designates
some object (a component of a vector or whatever).

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May 19, 2009  6:03 PM

Your suggestion "discriminant designates an access to ..." does not make sense.

Best I can do is: "discriminant is an access that designates ..." does make sense.

****************************************************************

From: Bob Duff
Sent: Tuesday, May 19, 2009  6:03 PM

> Your suggestion "discriminant designates an access to ..." does not 
> make sense.

I agree it makes no sense, but that's not my suggestion.  ;-) Sorry for being unclear.
My suggestion is to replace this:

    Otherwise, Accessor returns an object whose discriminant is an access to
    the element designated by Position.

with this:

    Otherwise, Accessor returns an object whose discriminant designates
    the element designated by Position.

The following also works:

    Otherwise, Accessor returns an object whose discriminant is an access value
    that designates the element designated by Position.

but I think it's unnecessarily verbose -- we know it's an access value, because it's
declared to be of an access type, just a few paragraphs earlier.

I don't think we ever use the phrase "an access to" in the RM.
(If we called the silly things "pointers", like the rest of the world does, wording
would be easier!)

Note: similar wording appears elsewhere in the AI.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, May 20, 2009  12:24 PM

> but I think it's unnecessarily verbose -- we know it's an access 
> value, because it's declared to be of an access type, just a few 
> paragraphs earlier.

OK, but I disagree. I really want to emphasize that an access (not some sort of
value) is being returned.
 
> I don't think we ever use the phrase "an access to" in the RM.
> (If we called the silly things "pointers", like the rest of the world 
> does, wording would be easier!)

I do realize that, which is why I did replace the "to" with "that designates".

> Note: similar wording appears elsewhere in the AI.

I only found 3 instances of "access to". The first one is in the !problem section,
which is informal but probably would be better off written properly anyway. The
second one is talking about taking 'Access, not the same thing at all. The third
one is in the !discussion, again informal text, but I changed it anyway.

****************************************************************

From: Tucker Taft
Sent: Thursday, May 21, 2009  5:27 AM

I had a couple of "waking up" thoughts, as Jimmy Carter used to call them:

   1) Since formal parameters of a discriminated type
      have a 'Constrained attribute, we can accommodate
      Randy's desire to relax the matching rules somewhat
      for explicitly aliased formal parameters of a
      discriminated type.

      For 'Access, since there is no 'Constrained attribute
      for heap objects, we have to have tighter matching
      rules since you have to be able to decide whether
      a heap object is constrained from the declaration
      of the access type (now that we allow unconstrained
      objects in the heap).

      In fact, I don't think this will make much difference,
      but at least the wording will be simpler, since we
      don't need to talk about full views and partial views
      and all of that.  Essentially the idea is that the
      tighter matching requirements for 'Access will be
      enforced if and when someone takes 'Access of an
      explicitly aliased formal, by making use of the
      'Constrained attribute.

      Note that we could add a similar attribute for aliased
      formals of an array type, though it would indicate whether
      the actual's nominal *subtype* was constrained, because
      of course all array *objects* are constrained.

[Editor's note: The other thought pertains to AI05-0135-1 and is filed in that AI.]

****************************************************************

From: Randy Brukardt
Sent: Friday, May 22, 2009  12:45 PM

>    1) Since formal parameters of a discriminated type
>       have a 'Constrained attribute, we can accommodate
>       Randy's desire to relax the matching rules somewhat
>       for explicitly aliased formal parameters of a
>       discriminated type.
> 
>       For 'Access, since there is no 'Constrained attribute
>       for heap objects, we have to have tighter matching
>       rules since you have to be able to decide whether
>       a heap object is constrained from the declaration
>       of the access type (now that we allow unconstrained
>       objects in the heap).

That's exactly what I was talking about when I said that I thought a runtime check might
be better. I had forgotten that we already require the necessary mechanism for discriminated
types.

>       In fact, I don't think this will make much difference,
>       but at least the wording will be simpler, since we
>       don't need to talk about full views and partial views
>       and all of that.  Essentially the idea is that the
>       tighter matching requirements for 'Access will be
>       enforced if and when someone takes 'Access of an
>       explicitly aliased formal, by making use of the
>       'Constrained attribute.

Well, it would allow something like:

    type Rec (D : Natural := 100) is ...

    Cobj : aliased Rec(10);

    function Accessor (Param : aliased in out Rec; ...) return ...

    := Accessor (Cobj);

as long as the body of Accessor does not use 'Access of the entire parameter into an
access-to-Rec.

Actually, this seems pretty important, because the above is very similar to the form
of the bounded containers. The actual objects have bounds, but of course the subprograms
take unconstrained objects. (The difference is that the bounded containers, being tagged
objects, don't allow defaulted discriminants. But surely I can imagine someone building
an untagged container.)

    Acc : access Rec := Cobj'Access; -- Illegal.

(At least I hope the above is illegal, 'cause it would allow changing the discriminant
of a constrained object!! Acc.all := (D => 20, ...) surely is legal.)

>       Note that we could add a similar attribute for aliased
>       formals of an array type, though it would indicate whether
>       the actual's nominal *subtype* was constrained, because
>       of course all array *objects* are constrained.

Well, you've almost convinced me that that isn't important. I'd rather not add any runtime
overhead to the parameter passing if we can avoid it.

****************************************************************

From: Tucker Taft
Sent: Friday, May 22, 2009  2:12 PM

> Well, it would allow something like:
> 
>     type Rec (D : Natural := 100) is ...
> 
>     Cobj : aliased Rec(10);
> 
>     function Accessor (Param : aliased in out Rec; ...) return ...
> 
>     := Accessor (Cobj);
> 
> as long as the body of Accessor does not use 'Access of the entire 
> parameter into an access-to-Rec.

This would be legal even if we used the rules for 'Access, though I realize you would
need convincing.  The relevant paragraph is 3.10.2(27.2).  But I agree it is simpler
to explain and understand if we simply fall back on the availability of the 'Constrained
attribute.

> Actually, this seems pretty important, because the above is very 
> similar to the form of the bounded containers. The actual objects have 
> bounds, but of course the subprograms take unconstrained objects. (The 
> difference is that the bounded containers, being tagged objects, don't 
> allow defaulted discriminants. But surely I can imagine someone 
> building an untagged
> container.)

The only time "access Rec" doesn't allow "Cobj'Access"
is if there is a partial view of Rec that is constrained (that is, the partial view is
simply "type Rec is private;", and the discriminants are only visible in the private part).
We don't allow Cobj'Access in that case because the assumption is that all designated
objects are unconstrained (to avoid privacy breaking).  For a container either the
discriminants would be visible, or clients could never declare constrained objects,
so you would never bump into the problem.

But as I said, if by falling back on 'Constrained we can simplify the description and
make one R.R. happier, that's fine with me!

>     Acc : access Rec := Cobj'Access; -- Illegal.
> 
> (At least I hope the above is illegal, 'cause it would allow changing 
> the discriminant of a constrained object!! Acc.all := (D => 20, ...) 
> surely is
> legal.)

No it's not legal to change the discriminants through an access value, since
in most cases, heap objects are constrained. In 2005 we added an exception for
types whose partial view has no visible discriminant part -- those are presumed
*always* unconstrained in the heap, but of course only code that has visibility
on the full type would even notice.  At least that is what 3.10.2(27.2) is
*supposed* to be accomplishing. Apparently at least in your case, it accomplished
total obfuscation.  Perhaps a note (if only in the AARM) might be useful on this paragraph.

****************************************************************

From: Randy Brukardt
Sent: Friday, May 22, 2009  11:45 PM

...
> > Well, it would allow something like:
> > 
> >     type Rec (D : Natural := 100) is ...
> > 
> >     Cobj : aliased Rec(10);
> > 
> >     function Accessor (Param : aliased in out Rec; ...) return ...
> > 
> >     := Accessor (Cobj);
> > 
> > as long as the body of Accessor does not use 'Access of the entire 
> > parameter into an access-to-Rec.
> 
> This would be legal even if we used the rules for 'Access, though I 
> realize you would need convincing.  The relevant paragraph is 
> 3.10.2(27.2).  But I agree it is simpler to explain and understand if 
> we simply fall back on the availability of the 'Constrained attribute.

I obviously have had a brain meltdown, must be the sudden onset of summer (we seem
to have skipped spring altogether). But now I wonder if 'Constrained would be helpful.

> > Actually, this seems pretty important, because the above is very 
> > similar to the form of the bounded containers. The actual objects 
> > have bounds, but of course the subprograms take unconstrained 
> > objects. (The difference is that the bounded containers, being 
> > tagged objects, don't allow defaulted discriminants. But surely I 
> > can imagine someone building an untagged container.)
> 
> The only time "access Rec" doesn't allow "Cobj'Access"
> is if there is a partial view of Rec that is constrained (that is, the 
> partial view is simply "type Rec is private;", and the discriminants 
> are only visible in the private part).
> We don't allow Cobj'Access in that case because the assumption is that 
> all designated objects are unconstrained (to avoid privacy breaking).  
> For a container either the discriminants would be visible, or clients 
> could never declare constrained objects, so you would never bump into 
> the problem.

Humm. In that case, 'Constrained is definitely *not* what we want. We want static matching
in all cases unless the parameter subtype is discriminated and unconstrained (unconstrained
is the usual case, of course). And we don't want any checks at all unless the partial view
exception exists. While 'Constrained will be true for a passed-in constrained object. So we
would still need all of the "partial view" wording on the runtime check at the point of 'Access,
because that is the only case when we would want to check that. (We surely don't want to
check it for access-to-"ordinary"-unconstrained, because there is no reason to allow *less* here).

I don't quite buy the last sentence, although I agree that *clients* couldn't bump into the
problem. But if that is the case, we might as well just stick with the original legality rules
on the call, since it would be fairly hard for them to fail in normal usage, so long as people
avoid messing with aliased array parameters or aliased scalar parameters. And you'd convinced
me that we really don't care about those latter cases.

(That will come back to bite us, I suspect. BTW, you said that you couldn't remember the last
time someone complained about these static matching rules. As it turns out, it was Adam in
Ada-Comment waaaay back in March. Of 2009. Like I said, it is a *very* common complaint.)

I'll add some "alternative" discussion about potential runtime checks to avoid the static checks.

> >     Acc : access Rec := Cobj'Access; -- Illegal.
> > 
> > (At least I hope the above is illegal, 'cause it would allow 
> > changing the discriminant of a constrained object!! Acc.all := (D => 
> > 20, ...) surely is legal.)
> 
> No it's not legal to change the discriminants through an access value, 
> since in most cases, heap objects are constrained.

Well, you have convinced me that the above is legal. <PEDANT> And it is *legal* to try to
change the discriminants of a designated object: but it must raise Constraint_Error.</PENDANT>

> In 2005 we added an exception for types whose partial view has no 
> visible discriminant part -- those are presumed
> *always* unconstrained in the heap, but of course only code that has 
> visibility on the full type would even notice.  At least that is what 
> 3.10.2(27.2) is *supposed* to be accomplishing.
> Apparently at least in your case, it accomplished total obfuscation.  
> Perhaps a note (if only in the AARM) might be useful on this 
> paragraph.

I think there is such a note in the vicinity. But of course I thought I remembered how this
all works, rather than actually looking it up. Which doesn't always work out. :-) And what I
did look up I read in the paper RM, so I didn't see the AARM notes.
 
****************************************************************

Questions? Ask the ACAA Technical Agent