Version 1.5 of ais/ai-00240.txt

Unformatted version of ais/ai-00240.txt version 1.5
Other versions for file ais/ai-00240.txt
!standard E.2.2 (8)          02-05-09 AI95-00240/04
!standard E.2.2 (14)
!standard E.2.3 (14)
!class binding interpretation 00-10-04
!status Amendment 200Y 02-07-09
!status WG9 Approved 02-06-21
!status ARG Approved 7-0-1 01-10-07
!status work item 00-10-04
!status received 00-10-04
!reference AI95-00195
!qualifier Clarification
!priority Low
!difficulty Medium
!subject Stream attributes for limited types in Annex E
!summary
E.2.2(14) and E.2.3(14) should allow any type with available Read and Write stream attributes.
!question
The Technical Corrigendum changed 13.13.2(36/1) to allow calls to stream attributes for limited type extensions where the attribute was specified for an ancestor type:
An attribute_reference for one of these attributes is illegal if the type is limited, unless the attribute has been specified by an attribute_definition_clause or [(for a type extension)] the attribute has been specified for an ancestor type.
Several paragraphs in Annex E require the existence of stream attributes for a type: E.2.2(8), E.2.2(14/1), and E.2.3(14/1). None of these paragraphs have been updated to reflect the previous change. Should any of them be updated? (Yes for E.2.2(14), E.2.3(14), No for E.2.2(8)).
!recommendation
(See summary.)
!wording
AI95-00195 makes a further change in 13.13.2(36/1), introducing the idea of a stream-oriented attribute being "available". This change makes it easier to word the replacement paragraphs.
Change E.2.2(8) to use the phrase "specified by a visible attribute_definition_clause" as "user-specified attribute" is not defined and ignores visibility issues.
Change E.2.2(14/1) to say "each non-controlling formal parameter shall have either a nonlimited type or a type with available Read and Write stream attributes;"
Change E.2.3(14/1) to say "...or a formal parameter of a limited type unless that limited type has available Read and Write stream attributes;"
!discussion
Let's consider each paragraph separately.
For E.2.2(8):
if the full view of a type declared in the visible part of the library unit has a part that is of a non-remote access type, then that access type, or the type of some part that includes the access type subcomponent, shall have user-specified Read and Write attributes.
The intent of this paragraph is stated in AARM E.2.2(8.a): to avoid the use of the default implementation of the attributes. Thus, we do not want to include the new case here (as it potentially uses a default implementation for extension components). The wording should, however, be corrected to use the phrase "specified by a visible attribute_definition_clause", so that visibility issues are included, and a defined phrase is used rather than the vague "user-specified" wording.
E.2.2(14/1) says:
The primitive subprograms of the corresponding specific limited private type shall only have access parameters if they are controlling formal parameters; each non-controlling formal parameter shall have either a nonlimited type or a type with Read and Write attributes specified via an attribute_definition_clause;
The intent of this paragraph is that the attributes be available (see the Defect Report 8652/0083 for a discussion). Thus, it echoes the original 13.13.2(36/1). However, with the change to 13.13.2(36/1), this does not allow the use of type whose attributes were specified for an ancestor type. Thus, this should be changed to match 13.13.2(36/1).
E.2.3(14/1) says:
it shall not be, nor shall its visible part contain, a subprogram (or access-to-subprogram) declaration whose profile has an access parameter, or a formal parameter of a limited type unless that limited type has user-specified Read and Write attributes;
This paragraph has the same intent as E.2.2(14/1). Thus, the wording should be similar.
!corrigendum E.2.2(8)
Replace the paragraph:
by:
!corrigendum E.2.2(14/1)
Replace the paragraph:
by:
!corrigendum E.2.3(14/1)
Replace the paragraph:
by:
!ACATS test
An ACATS test is needed to verify that the new cases are implemented properly.
!appendix

From: Randy Brukardt
Sent: Wednesday, October 04, 2000 2:26 PM

The Technical Corrigendum changes 13.13.2(36/1) to allow calls to stream
attributes for limited type extensions where the attribute was specified for
an ancestor type:
    An attribute_reference for one of these attributes is illegal if the
    type is limited, unless the attribute has been specified by an
    attribute_definition_clause or [(for a type extension)] the attribute has
    been specified for an ancestor type.

Several paragraphs in Annex E require the existence of stream attributes for
a type: E.2.2(8), E.2.2(14/1), and E.2.3(14/1). None of these paragraphs
have been updated to reflect the previous change.

For E.2.2(8):
   if the full view of a type declared in the visible part of the
   library unit has a part that is of a non-remote access type, then
   that access type, or the type of some part that includes the access type
   subcomponent, shall have user-specified Read and Write attributes.

The intent of this paragraph is stated in E.2.2(8.a): to avoid the use of
the default implementation of the attributes. Thus, we do not want to
include the new case here (as it potentially uses a default implementation
for extension components). I'm not sure if this paragraph is intended to
allow the use of inherited user-defined attributes, as it does not use the
magic wording "specified by an attribute_definition_clause" (which is
specifically defined to include inherited user-defined routines). It
definitely does not include the use of attribute of type extensions which
has an ancestor with an inherited user-defined attribute, as that
technically is a "default implementation" -- and that is what we want.

E.2.2(14/1) says:
  The primitive subprograms of the corresponding specific limited private type
  shall only have access parameters if they are controlling formal parameters;
  each non-controlling formal parameter shall have either a nonlimited type or
  a type with Read and Write attributes specified via an
  attribute_definition_clause;

The intent of this paragraph is that the attributes be callable (see the
Defect Report 8652/0083 for a discussion). Thus, it echoes the original
13.13.2(36). However, with the change to 13.13.2(36), this does not allow
the use of type whose attributes were specified for an ancestor type. It
seems that this should be changed to match 13.13.2(36). [If that is done, it
may be best to define a term "callable stream attribute" in 13.13.2(36), and
then use that here, to avoid synchronization problems in the future.]

E.2.3(14/1) says:
  it shall not be, nor shall its visible part contain, a subprogram (or
  access-to-subprogram) declaration whose profile has an access parameter, or
  a formal parameter of a limited type unless that limited type has
  user-specified Read and Write attributes;

The intent of this paragraph is not given anywhere. It seems to me that the
intent is similar to that of E.2.2(14). Thus, it is strange that the wording
differs so much; it seems to not allow any inherited user-specified
attributes, and definitely does not allow attributes of type extensions
which has an ancestor with an inherited user-defined attribute. Therefore,
the wording of this item should be changed in the same way that E.2.3(14/1)
is.

****************************************************************
Questions? Ask the ACAA Technical Agent