CVS difference for ai05s/ai05-0142-4.txt
--- ai05s/ai05-0142-4.txt 2009/05/17 05:25:14 1.1
+++ ai05s/ai05-0142-4.txt 2009/05/19 22:33:25 1.2
@@ -1,4 +1,4 @@
-!standard 3.10(9/2) 09-05-17 AI05-0142-4/01
+!standard 3.10(9/2) 09-05-19 AI05-0142-4/02
!class Amendment 09-05-17
!status work item 09-05-17
!status received 09-05-17
@@ -21,12 +21,11 @@
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
+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 to the element type. However, this is problematic as it is difficult to
+access to 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
@@ -52,15 +51,15 @@
Add somewhere in 3.10.2(6-16): [Q: Where??]
-The accessibility level of a formal aliased parameter in a function body
-is that that the return object will have after a return statement completes
+The accessibility level of an explicitly aliased formal parameter in a function body
+is the level that the return object will have after a return statement 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
+[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
-garbage. (See the Language Design Principles below.) But this depends on what
+checks and associated overhead. (See the Language Design Principles below.) 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
@@ -72,44 +71,48 @@
Replace 6.1(15/2) by:
parameter_specification ::=
- defining_identifier_list : mode [aliased] [null_exclusion] subtype_mark [:= default_expression]
+ defining_identifier_list : [aliased] mode [null_exclusion] subtype_mark [:= default_expression]
| defining_identifier_list : access_definition [:= 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.]
-
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(10):
-An *aliased parameter* is a formal parameter that includes the reserved word *aliased*.
+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 aliased parameters}, and, for access parameters or
-access result types, the designated subtypes statically match, or the designated profiles are
-subtype conformant.
+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 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.
+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 aliased parameters live as long as the function result; then we can allow them
+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 aliased parameter, the type of the actual parameter shall be
-tagged or the actual parameter shall be an aliased view of an object.
+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.
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.
+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.
In a function call, the accessibility level of the actual object
-for each aliased parameter shall not be statically deeper than
+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
@@ -117,8 +120,8 @@
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 aliased parameters are either tagged or required to be objects,
-there is always an object (possibly anonymous) to talk about. This is discussing
+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).
@@ -130,43 +133,55 @@
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 object is
-the same as or includes that of master of the function result.
+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
-aliased parameters would have to carry accessibility levels).
+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 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.
+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 aliased parameters of functions is needed for the same reason,
-as access discriminants of the returned object may designate one of these parameters.
+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 aliased parameters of functions is
-not necessarily as long as the master of the object being initialized (if the funciton
+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 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
+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) [note that
the names of the type, discriminant, and function are TBD].
@@ -174,6 +189,8 @@
type Accessor_Type (Element : not null access Element_Type) is
tagged limited private;
+[Bob recommends just using "E" for the name of the discriminant.]
+
Accessor_Type needs finalization.
A default-initialized object of type Accessor_Type propagates Program_Error.
@@ -185,31 +202,31 @@
this case would take extra work, we define it to raise an exception.
- function Accessor (Container : in out aliased Vector; Position : in Cursor)
+ function Accessor (Container : aliased 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.
+Otherwise, Accessor returns an object whose discriminant is an access 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 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)
+ function Accessor (Container : aliased 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.
+Accessor returns an object whose discriminant is an access 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 Accessor exists and
+has not been finalized.
The element designated by Position is not an empty element after successful
completion of this operation.
@@ -235,27 +252,20 @@
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 (Position : aliased in Cursor) return RO_Accessor_Type;
- function RO_Accessor (Container : in aliased Vector; Index : in Index_Type)
+ function RO_Accessor (Container : aliased 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 aliased parameters of functions is defined
+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.
-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
@@ -298,8 +308,8 @@
---
-We don't want to treat all parameters of functions like aliased parameters for compatibility
-and wording reasons.
+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
@@ -318,6 +328,48 @@
---
+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).
+
+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 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
@@ -327,7 +379,7 @@
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;
+function Accessor (C : aliased in out Vector; I : Index_Type) return access Element_Type;
Now consider the following program fragments:
@@ -395,7 +447,7 @@
...
end Main;
-Now, in the canonical implementation for a vector, all of the data is stored in
+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.
@@ -415,14 +467,15 @@
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.
+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 Accessor function could be used (based on a recent example from comp.lang.ada):
+The new Accessor function could be used (based on a recent example from
+comp.lang.ada):
with Ada.Containers.Vectors;
procedure Check is
@@ -445,9 +498,9 @@
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.
+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:
@@ -457,15 +510,16 @@
(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:
+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.
+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:
@@ -473,9 +527,10 @@
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.
+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:
@@ -483,10 +538,11 @@
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.
+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:
+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);
@@ -500,5 +556,1012 @@
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.
****************************************************************
Questions? Ask the ACAA Technical Agent