Version 1.3 of ai12s/ai12-0085-1.txt
!standard E.2.2(17/2) 13-12-11 AI05-0085-1/02
!class binding interpretation 13-10-28
!status Corrigendum 2014 13-12-11
!status ARG Approved 10-0-0 13-11-15
!status work item 13-10-28
!status received 13-07-11
!priority Low
!difficulty Easy
!qualifier Omission
!subject Missing aspect cases for Remote_Types
!summary
A remote access-to-class-wide type cannot specify the Storage_Pool or
Storage_Size aspects.
!question
E.2.2(17/2) talks about the Storage_Pool and Storage_Size attributes. It
doesn't mention the corresponding aspects, which appears to allow specifying
them. Should specifying them be disallowed as well? (Yes.)
!recommendation
(See Summary.)
!wording
Modify E.2.2(17/2):
* The Storage_Pool attribute is not defined for a remote access-to-class-wide
type; the expected type for an allocator shall not be a remote
access-to-class-wide type. A remote access-to-class-wide type shall not be
an actual parameter for a generic formal access type. The Storage_Size
attribute of a remote access-to-class-wide type yields 0[; it is not allowed
in an attribute_definition_clause].{ The Storage_Pool and Storage_Size aspects
shall not be specified for a remote access-to-class-wide type.}
!discussion
[Author's note: I noticed when writing this up that the same problem
occurs for the Storage_Pool aspect as for the Storage_Size aspect. Not sure
how I missed that originally - probably the same way that we missed the entire
issue previously. Anyway, I wrote this up assuming that both aspects need to
be banned from being specified.]
We definitely don't want these aspects specified by any means, so we adjust the
wording to ensure that specifying via an aspect_specification is covered. The
existing wording definitely does not cover that, as an attribute is not an
aspect, and an attribute_definition_clause is not an aspect_specification.
The text about the Storage_Pool attribute not being defined is still necessary,
because we don't want to allow reading the aspect via the attribute as well as
not wanting to allow it to be specified.
!corrigendum E.2.2(17/2)
Replace the paragraph:
- The Storage_Pool attribute is not defined for a remote
access-to-class-wide type; the expected type for an allocator shall not be
a remote access-to-class-wide type. A remote access-to-class-wide type shall
not be an actual parameter for a generic formal access type. The Storage_Size
attribute of a remote access-to-class-wide type yields 0; it is not allowed in
an attribute_definition_clause.
by:
- The Storage_Pool attribute is not defined for a remote
access-to-class-wide type; the expected type for an allocator shall not be
a remote access-to-class-wide type. A remote access-to-class-wide type shall
not be an actual parameter for a generic formal access type. The Storage_Size
attribute of a remote access-to-class-wide type yields 0. The Storage_Pool and
Storage_Size aspects shall not be specified for a remote access-to-class-wide
type.
!ASIS
No changes needed.
!ACATS test
An ACATS B-Test is needed to ensure that these attributes cannot be specified
for remote access-to-classwide types.
!appendix
From: Randy Brukardt
Sent: Thursday, July 11, 2013 9:21 PM
[A case of what Steve calls "heat vision"!] I'm processing AI12-0072-1, which
inserts some text after existing E.2.2(17/2). So I idly re-read the paragraph
as I copied it:
* The Storage_Pool attribute is not defined for a remote access-to-class-wide
type; the expected type for an allocator shall not be a remote
access-to-class-wide type. A remote access-to-class-wide type shall not be
an actual parameter for a generic formal access type. The Storage_Size
attribute of a remote access-to-class-wide type yields 0; it is not allowed
in an attribute_definition_clause.
Immediately I wonder about the Storage_Size *aspect*. Clearly, we don't want to
allow specifying that, either, but I don't see how this wording accomplishes
that (it talks specifically about the attribute in an
attribute_definition_clause, and an aspect_specification is neither).
I think we need a sentence like:
"Similarly, the Storage_Size aspect shall not be specified in an
aspect_specification for a remote access-to-classwide type."
We could get more radical, and replace all of the text after the semicolon in
the original paragraph with:
"the Storage_Size aspect shall not be specified for a remote
access-to-classwide type."
which probably is better because it covers all possible cases, including any
that we haven't invented yet.
Thoughts?? I'll be happy to write up a simple AI to deal with this if
everyone agrees.
****************************************************************
From: Jeff Cousins
Sent: Friday, July 12, 2013 1:04 AM
First thoughts are that I prefer the second proposal.
****************************************************************
From: Tucker Taft
Sent: Monday, July 15, 2013 11:22 AM
I also prefer the general aspect-based restriction.
****************************************************************
Questions? Ask the ACAA Technical Agent