CVS difference for ais/ai-00385.txt
--- ais/ai-00385.txt 2004/10/28 16:52:26 1.2
+++ ais/ai-00385.txt 2004/12/09 19:55:37 1.3
@@ -1,8 +1,10 @@
-!standard 03.03.01 (02) 04-10-28 AI95-00385/02
+!standard 03.03.01 (02) 04-12-01 AI95-00385/03
!standard 03.03.01 (08)
!standard 03.03.01 (16)
!standard 03.10.02 (11)
!class amendment 04-10-25
+!status Amendment 200Y 04-12-01
+!status ARG Approved 8-1-1 04-11-19
!status work item 04-10-25
!status received 04-10-25
!priority High
@@ -11,11 +13,8 @@
!summary
-Stand-alone objects of an anonymous access type are introduced. <<In order
-to avoid confusion, constants of such types are not permitted.>>
+Stand-alone objects of an anonymous access type are introduced.
-Delete stuff in << >> for option 2, see !discussion.
-
!problem
AI-230 introduced anonymous access types in wider contexts than just access
@@ -36,37 +35,23 @@
It is now considered that disallowing stand-alone variables was a mistake and
is likely to lead to frustration, anger and derision on the part of users.
-(Nanny Ada strikes again.)
!proposal
It is proposed that stand-alone objects be permitted of an anonymous access
type.
-<<However, it is also proposed that stand-alone constants remain forbidden
-in order to avoid confusion between the constancy of the object which
-contains the access value and the constancy of the value of the object being
-accessed.>>
-
-Delete stuff in << >> for option 2, see !discussion.
-
!wording
Replace 3.3.1(2) by
object_declaration ::=
- defining_identifier_list : [aliased] [constant] subtype_indication
- [:= expression]
- | defining_identifier_list : [constant] access_definition
- [:= expression]
- | defining_identifier_list : [aliased] [constant] array_type_definition
- [:= expression]
+ defining_identifier_list : [aliased] [constant] subtype_indication [:= expression]
+ | defining_identifier_list : [constant] access_definition [:= expression]
+ | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression]
| single_task_declaration
| single_protected_declaration
-NB delete constant before access_definition in the above for option 3 - see
-!discussion.
-
Modify 3.3.1(8)
The subtype_indication{, access_definition,} or full type definition of
@@ -78,24 +63,15 @@
single_task_declaration, or single protected_declaration is first
elaborated. This creates the nominal subtype (and the anonymous
type in the [latter three]{last four} cases.
-
-Fowler says former and latter should only be used when there are just two cases.
-
-Add after 3.3.1(24)
-
-AARM note
- Stand-alone constants of an anonymous access type are not permitted
- in order to avoid confusion between access constant and constant access.
+[Editor's note: Fowler says former and latter should only be used when there are just
+two cases, thus the word is changed to last.]
-end AARM note.
-
-NB delete the above AARM note for option 2 - see !discussion.
-
Add after 3.10.2(11)
- The accessibility level of the anonymous access type in an
- object_declaration having such a type is the same as the level of the object.
+ The accessibility level of the anonymous access type
+ defined by an access_definition of an object_declaration is
+ the same as that of the declared object.
!discussion
@@ -145,7 +121,6 @@
AI-230 says
-
We considered allowing anonymous access types in stand-alone
variable declarations. However the general philosophy for accessibility
levels (described above in the proposal section) would force
@@ -159,8 +134,7 @@
used in most cases where a constant would have been useful.
As an alterantive (sic), we considered allowing variables of an anonymous
- access type
- to carry run-time accessibility levels across assignment
+ access type to carry run-time accessibility levels across assignment
statements with an accompanying accessibility check as well to handle
up-level assignments. But this would totally change the model,
since in all other cases we have fully determined the accessibility level
@@ -211,8 +185,8 @@
A stronger point is that it is considered dangerous that the reversal of
two words should make such a lot of difference. However, there are other
-places in the language where small changes have a dramatic effect (e.g.
-replacing or by else in a timed entry call).
+places in the language where small changes have a dramatic effect (for
+example, replacing or by else in a timed entry call).
It is instructive to compare the following using named access types. In one
case we write
@@ -262,15 +236,9 @@
Moreover, some style guides insist on the use of constants and there is
evidence that some compilers are able to generate better code for constants.
-
-After much discussion it was decided to chose option ??
+After much discussion it was decided to chose option 2.
-(Those who think that access constant versus constant access is confusing
-might like to consider whether they do not find the problems of access to
-arrays and constraints more so. But this is an aside and water long under
-the bridge - let's make them obsolete. Tchah. A pox on it.)
-
!example
(See discussion.)
@@ -279,28 +247,19 @@
@drepl
@xcode<@fa<object_declaration ::=
- defining_identifier_list : [>ft<@b<aliased] [constant>>@fa<]
- subtype_indication [:= expression]
- | defining_identifier_list : [>ft<@b<aliased] [constant>>@fa<]
- array_type_definition [:= expression]
+ defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] subtype_indication [:= expression]
+ | defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] array_type_definition [:= expression]
| single_task_declaration
| single_protected_declaration>>
@dby
@xcode<@fa<object_declaration ::=
- defining_identifier_list : [>ft<@b<aliased] [constant>>@fa<]
- subtype_indication [:= expression]
- | defining_identifier_list : [>ft<@b<constant>>@fa<]
- access_definition [:= expression]
- | defining_identifier_list : [>ft<@b<aliased] [constant>>@fa<]
- array_type_definition [:= expression]
+ defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] subtype_indication [:= expression]
+ | defining_identifier_list : [>@ft<@b<constant>>@fa<] access_definition [:= expression]
+ | defining_identifier_list : [>@ft<@b<aliased>>@fa<] [>@ft<@b<constant>>@fa<] array_type_definition [:= expression]
| single_task_declaration
| single_protected_declaration>>
-NB delete constant before access_definition in the above for option 3
-- see !discussion
-
-
!corrigendum 03.03.01(8)
@drepl
@@ -334,9 +293,9 @@
@xbullet<The accessibility level of a derived access type is that of
its ultimate ancestor.>
@dinss
-@xbullet<The accessibility level of the anonymous access type in an
-@fa<object_declaration> having such a type is the same as the level
-of the object.>
+@xbullet<The accessibility level of the anonymous access type
+defined by an @fa<access_definition> of an @fa<object_declaration> is
+the same as that of the declared object.>
!ACATS test
Questions? Ask the ACAA Technical Agent