CVS difference for ais/ai-00230.txt
--- ais/ai-00230.txt 2003/02/05 21:03:23 1.8
+++ ais/ai-00230.txt 2003/06/27 23:46:27 1.9
@@ -1,4 +1,4 @@
-!standard 3.10 (01) 03-02-05 AI95-00230/04
+!standard 3.10 (01) 03-06-20 AI95-00230/05
!class amendment 00-04-13
!status work item 00-04-13
!status received 00-04-13
@@ -10,8 +10,8 @@
More general use of anonymous access types is proposed, to allow the
flexibility of implicit conversion and run-time accessibility checking
-to be used in more contexts, including as components and as stand-alone
-constants. A separate AI (AI-00325) investigates using anonymous access
+to be used in more contexts, including as components and in object renamings.
+A separate AI (AI-00325) investigates using anonymous access
types as function result types.
NOTE: This AI is also related to AI-00231, which allows anonymous access
@@ -58,23 +58,24 @@
!proposal
-The "access_definition" syntactic category (see AI-00231) is permitted in more
-places than just as formal parameters and discriminants. In addition to the
-current places (IN parameters and discriminants of limited types) it is
-permitted in stand-alone constant declarations, formal IN objects,
-component definitions, and for discriminants of non-limited types. The type
-associated with constant, formal IN, or component is an anonymous access type,
-which permits implicit conversions from other access types with appropriately
-compatible designated subtypes (as defined by 4.6(13-17)).
+The "access_definition" syntactic category (see 3.10(6); also see AI-00231) is
+permitted in more places than just as formal parameters and discriminants. In
+addition to the current places (IN parameters and discriminants of limited
+types) it is permitted in object renaming declarations, component definitions,
+and for discriminants of non-limited types. The type associated with the
+renaming or the component is an anonymous access type, which permits implicit
+conversions from other access types with appropriately compatible designated
+subtypes (as defined by 4.6(13-17)).
The accessibility level of an anonymous access type is determined at the
time when the access_definition is elaborated. The general accessibility
level "philosophy" is:
a) For an access object that cannot be altered during its lifetime (in
-parameter, stand-alone constant, IN object, discriminant of a limited
-type, possibly function return value), its level may be determined by
-the accessibility level of its initial value or enclosing object.
+parameter, discriminant of a limited type, possibly
+function return value), its level may be determined by the accessibility
+level of its initial value or enclosing object. In addition, a renaming
+inherits the accessibility level from the renamed/actual object.
b) For others (i.e. other kinds of components) the accessibility level
must be determined by the level of its declaration. This is necessary
@@ -88,17 +89,28 @@
them to have a level determined by their declaration rather than initial
value. This might create confusion when copying an access parameter into
a local variable and unintentionally losing the accessibility level
-information. By only allowing constants, and having them preserve the
-accessibility level information, we avoid this possible problem.]
+information. By only allowing renamings, and having
+them preserve the accessibility level information, we avoid this
+possible problem. Because allowing constants but not variables
+introduced a non-orthogonality, we chose to allow renamings which can be
+used in most cases where a constant would have been useful.
+
+NOTE 2: We also considered allowing generic formal objects. However,
+this adds significantly to the complexity of the proposal, with
+relatively little added benefit. Just supporting it for IN mode
+formal objects would be feasible, as it would be nearly identical
+to the support required for IN parameters, and presumably use
+similar syntax, with no "mode" allowed. This seems like a possible
+further extension, probably having both minor cost and minor benefit.]
Applying this general philosophy to the specific cases means that for a
-constant declaration/formal IN object, the level is the same as the
-level of the type of the initial value. For a component definition, or a
-discriminant of a nonlimited type, the level is the same as that of the
-enclosing composite type. As in the current language, IN parameters take
-their level from the initial value, and discriminants of limited types
-take their level from the enclosing composite *object* (as opposed
-to enclosing type).
+renaming, the level is the same as the level of the type of the
+renamed object. For a component definition or a discriminant of a
+nonlimited type, the level is the same as that of the enclosing
+composite type. As in the current language, IN parameters take their
+level from the initial value, and discriminants of limited types take
+their level from the enclosing composite *object* (as opposed to
+enclosing type).
There is a special predefined equality (and matching inequality) operator
declared in package Standard which requires at least one of the parameters to
@@ -108,10 +120,9 @@
The storage pool to be used for an allocator of an anonymous access type
is determined by the context in which it appears:
-a) As the value for an IN parameter, constant, or formal IN object of an
- anonymous access type, an anonymous storage pool whose storage is
- reclaimed when the function returns, or at the end of the constant's
- or formal IN object's scope;
+a) As the value for an IN parameter, an anonymous storage pool whose storage is
+ reclaimed when the function returns, or at the end of the
+ or instantiation's scope;
b) As the initial value for a discriminant of a limited type, the same
storage pool as used for the enclosing object, if it is created by
@@ -125,27 +136,6 @@
!wording
-Add to paragraph 3.3.1(2):
-
- object_declaration ::= access_definition [:= expression];
-
-Change 3.3.1(5) to:
-
- An object_declaration without the reserved word CONSTANT that has
- a subtype_indication or array_type_definition defining an indefinite
- subtype shall have an initialization expression. An initialization
- expression shall not be given if the object is of a limited type.
-
-Change the first sentence of 3.3.1(6) to:
-
- An object_declaration with an access_definition or the reserved word
- CONSTANT declares a constant object. ... -- rest remains the same
-
-Add "access_definition, " to the first sentence of paragraph 3.3.1(16):
-
- The subtype_indication, array_type_definition, access_definition,
- single_task_declaration, ...
-
Change 3.6(7) as follows:
component_definition ::= [aliased] subtype_indication | access_definition
@@ -163,7 +153,7 @@
... For the elaboration of a component_definition of a
component_declaration or the discrete_subtype_definition of an
- entry_declaration for an entry family (see 9.5.2), {if the compoent
+ entry_declaration for an entry family (see 9.5.2), {if the component
subtype is defined by an access_definition or} if the constraint or
range of the subtype_indication or discrete_subtype_definition is not
a per-object constraint, then the {access_definition,}
@@ -176,12 +166,8 @@
Add the following paragraph before 3.10.1(12):
The accessibility level of the anonymous access type defined by an
- access_definition of an object_declaration (or
- formal_object_declaration in an instance) is the same as that of the
- view designated by the value of the initialization_expression (or
- actual). If the initialization_expression (or actual) is an
- allocator, this is the accessibility level of the innermost enclosing
- master.
+ access_definition of an object_renaming_declaration is the same as that of
+ the renamed object (view).
Change paragraph 3.10.1(12) as follows:
@@ -193,58 +179,57 @@
composite type.}
-Change paragraph 12.4(2) as follows:
+Change paragraph 8.5.1(2) as follows:
- formal_object_declaration ::=
- defining_identifier_list : mode subtype_mark [:= default_expression];
- | defining_identifier_list : access_definition [:= default_expression];
-
- Change 12.4(9) as follows:
-
- A formal_object_declaration declares a generic formal object. {If
- the mode is omitted or the declaration has an access_definition, }the
- default mode is IN. For a formal object of mode IN, the nominal
- subtype is the one denoted by the subtype_mark {or defined by the
- access_definition} in the declaration of the formal. For a formal
- object of mode IN OUT, ... -- no change
+ object_renaming_declaration ::=
+ defining_identifier : subtype_mark RENAMES object_name;
+ | defining_identifier : access_definition RENAMES object_name;
+
+Change paragraph 8.5.1(3) as follows:
+
+ The type of the object_name shall resolve to the type determined by
+ the subtype_mark{, or in the case where the type is defined by an
+ access_definition, to an anonymous access type whose designated type
+ is the same as that of the access_definition}.
+
+[NOTE: If AI-231 is adopted, then 8.5.1(4) should probably include a
+legality rule that requires the access_definition to be
+access-to-constant if and only if the renamed object is
+access-to-constant. Alternatively, we could allow the
+access-to-constantness to be carried over from the renamed object in the
+same way that constantness is.]
+Change paragraph 8.5.1(6) as follows:
+
+ ... any constraint implied by the subtype_mark {or access_definition}
+ of the object_renaming_declaration is ignored.
+
!example
package P is
type T is ...
- end P;
- package P2 is
type Rec(D : access String := new String'("")) is record
- F : access constant T;
- G : access all T not null := new T;
- H : access all T := null;
+ F : access T; -- in the absence of AI-231, will raise Constraint_Error
+ -- if allowed to default initialize to null.
+ G : access T'class := new T;
end record;
+
+ R : Rec := (D => new String'("Hello"), F => new T, G => new T);
- Y : access String := new String'("Hello There");
- -- I believe the "constant" should be implicit here,
- -- analogous to the existing rule for access parameters.
- -- The general rule is that "access" implies read only
- -- if that is possible in the given context.
- -- Only non-discrimiant record components
- -- will be directly assignable; discriminants of non-limited,
- -- unconstrained objects can be changed, but as usual only
- -- by assigning to the enclosing object.
-
- -- Essentially, the syntax for a stand-alone object declaration
- -- with an access_definition instead of a subtype_indication will not
- -- allow the reserved word "constant"
- -- before the access_definition, but it will always
- -- declare a constant object, including possibly a deferred constant.
-
- generic
- R : in Rec;
- Z : access T := R.G; -- The "in" must be omitted here.
- package What_Fun is ...
+ Y : access String renames R.D;
- package Instance is new What_Fun(new T'(...));
+ function Fun(X : access Rec) return Integer;
- end P2;
+ end P;
+
+ package body P is
+ function Fun(X : access Rec) return Integer
+ Disc : access String renames X.D;
+ begin
+ return 123;
+ end Fun;
+ end P;
!discussion
@@ -259,8 +244,8 @@
parameters. Furthermore, it doesn't handle potentially null values. Finally, it
cannot be used for record or array components (other than access
discriminants). [Note that the "null value" problem is solved in AI-231. We
-will make no further mention of this problem, and simply presume the
-generalization of access_definition proposed in AI-231 is in effect.]
+will make no further mention of this problem; see AI-231 for more discussion
+of this issue.]
Explicit access type conversions can be used to provide the desired
substitutability, but scattering type conversions around muddies the waters,
@@ -292,10 +277,10 @@
they seemed to create more problems than they solved, and are not needed
if we allow anonymous access types in component declarations.
-We have proposed to allow anonymous access types in constant declarations,
-formal IN objects, component definitions, and possibly function results. We considered
-broadening this to include stand-alone variable declarations, and variables
-declared as [IN] OUT parameters or IN OUT formal objects, but that created
+We have proposed to allow anonymous access types in object renamings,
+component definitions, and possibly function results. We considered
+broadening this to include stand-alone object declarations, and variables
+declared as [IN] OUT parameters or formal objects, but that created
the possibility of confusion about whether accessibility level information
is lost when copying an access parameter to a local variable. Alternatively,
the variable could retain the accessibility level information, but then
@@ -306,25 +291,26 @@
at the point of the elaboration of the anonymous access type.
We handle updatable components by specifying that their accessibility
-level is determined by the enclosing composite type. This provides
-the advantages of implicit conversion, without needing run-time
+level is determined by the enclosing composite type. This provides the
+advantages of implicit conversion, without needing run-time
accessibility levels for individual components.
We have split out issues relating to anonymous function result types
-into a separate AI-00325, so this one can be evaluated without getting bogged
-down in the implementation issues associated with function returns.
+into a separate AI-00325, so this one can be evaluated without getting
+bogged down in the implementation issues associated with function
+returns.
-Similarly, issues relating to supporting access-to-constant
-and null-allowing anonymous access types are in AI-00231.
+Similarly, issues relating to supporting access-to-constant and
+null-allowing anonymous access types are in AI-00231.
Implementation Issues:
-Constant declarations with access_definitions are no harder to support than
-access parameters (ditto goes for formal IN objects).
+Object renaming declarations with access_definitions are no harder to
+support than other renamings.
-Component declarations with access_definitions have no special accessibility
-level issues, because the level is determined just like a named access
-type.
+Component declarations with access_definitions have no special
+accessibility level issues, because the level is determined just like a
+named access type.
Other alternatives considered:
Questions? Ask the ACAA Technical Agent