Version 1.1 of ai12s/ai12-0085-1.txt

Unformatted version of ai12s/ai12-0085-1.txt version 1.1
Other versions for file ai12s/ai12-0085-1.txt

!standard E.2.2(17/2)          13-10-28 AI05-0085-1/01
!class binding interpretation 13-10-28
!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-classwide 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.)
!reecommendation
(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-classwide 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.
!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