Version 1.5 of ai22s/ai22-0004-1.txt

Unformatted version of ai22s/ai22-0004-1.txt version 1.5
Other versions for file ai22s/ai22-0004-1.txt

!standard 13.12.1(2/2)          22-02-03 AI22-0004-1/04
!class binding interpretation 22-01-13
!status Corrigendum 1-2022 22-02-03
!status ARG Approved 16-0-0 22-02-03
!status work item 21-11-11
!status received 21-11-11
!priority Very_Low
!difficulty Easy
!subject Permissions of 4.1.4 and No_Implementation_Attributes
!summary
All of the implementation permissions of 4.1.4 are revoked by the No_Implementation_Attributes restriction (as opposed to only the permission to define new attributes).
!issue
In RM 4.1.4(13/5-15/5), implementations are granted permission to extend the definition of language-defined attributes in some cases. Should the No_Implementation_Attributes restriction defined in RM 13.12.1(2/2) revoke this permission? (Yes.)
!recommendation
(See Summary.)
!wording
Add a new sentence in the middle of 13.12.1(2/2):
No_Implementation_Attributes
There are no implementation-defined attributes. {There are no implementation-defined extensions to the definition of any language-defined attribute (see 4.1.4).} This restriction applies only to the current compilation or environment, not the entire partition.
!discussion
The No_Implementation_Attributes restriction is intended to make it easier to write portable code by disallowing uses of attributes that might otherwise be accepted by one implementation but rejected by another. A user who wants to write such portable code almost certainly also wants to reject uses of attributes that rely on any of the implementation permissions of 4.1.4(13/5-15/5), not just the permission to define new attributes. That's especially true of the permission of 4.1.4(15/5), as the semantics of the attribute are implementation-defined (and thus are not likely to be the same on different implementations).
!corrigendum 13.12.1(2/2)
Replace the paragraph:
No_Implementation_Attributes
There are no implementation-defined attributes. This restriction applies only to the current compilation or environment, not the entire partition.
by:
No_Implementation_Attributes
There are no implementation-defined attributes. There are no implementation-defined extensions to the definition of any language-defined attribute (see 4.1.4). This restriction applies only to the current compilation or environment, not the entire partition.
!ACATS test
It would be possible to write a B-test that attempts to violate the restriction using attributes like Float'Small (from Ada 83) and Duration'Rounding. One would use the attributes in a test package without the restriction and a "-- N/A => Error" error tag, and then in a package with the restriction and a "-- ERROR:" tag.
!appendix

From: Steve Baird
WG 9 Review issue #133 - May 14, 2021

We say "An implementation may extend the definition of a language-defined
attribute ... in the following cases:", but 13.12.1 does not talk about
how this interacts with the No_Implementation_Attributes restriction.
Was this intended?

****************************************************************

From: Tucker Taft
WG 9 Review issue #133 - May 29, 2021

Good question, but not something we can resolve now. Deferred to next 
time! ;-)

****************************************************************

From: Randy Brukardt
WG 9 Review issue #133 - May 29, 2021

Certainly no one considered that. Given the very strict restrictions on 
extending language-defined attributes, I would argue that there is no problem
 - these attributes are not considered impl-def (especially since they are 
based either on previous or likely future standards). The wording of 
13.12.1(2/2) is rather ambiguous, though, one could read it to mean
"attributes with implementation-defined results". That would knock out 
many language-defined attributes (even Size and Alignment), so it doesn't 
seem likely that was intended.

So I don't think there is a problem here, but I'm OK with deferring the issue 
so that it can be considered more carefully (and perhaps the 13.12.1 wording 
should be cleaned up).

****************************************************************

Questions? Ask the ACAA Technical Agent