AI22-0065-1

!standard C(1)                                        23-05-29  AI22-0065-1/02

!standard D(1)

!class binding interpretation 23-03-22

!status work item 23-03-22

!status received 23-03-22

!priority Low

!difficulty Medium

!qualifier Clarification

!subject Specialized Needs Annexes should be normative

!summary

Drop the mention of optionality for Annexes, and simply indicate that conformance is defined separately for the core and for each specialized needs annex.

!issue

The JTC1 Directives, Part 2 are the rules governing the contents of the Ada Standard. One rule that has caused trouble is that Annexes can only be treated as normative if they contain nonoptional requirements (as Ada Annexes A, B, and J do). "Optional requirements", like those given in the Specialized Needs Annexes, do not make the annexes normative.

Our intent has been that anything that implementers are supposed to follow should be normative. Thus, the fact that the Specialized Needs Annexes cannot be normative is uncomfortable. One way to make them normative might be to organize them more like Annex B, with a small required part and a larger optional part.

Alternatively, we could simply drop the whole distinction between optional and non-optional requirements, since there is not a general rule that an ISO standard is all-or-nothing, despite the all-or-nothing history of the Ada standard. Instead, we can indicate that conformance for the core and each annex are defined separately. The C standard does something similar, where they have two forms of conformance, a “conforming hosted implementation” and a “conforming freestanding implementation.”

The most relevant paragraphs are the following:

RM 1.1.2(17):

All implementations shall conform to the core language. In addition, an implementation may conform separately to one or more Specialized Needs Annexes.  …

and RM 1.1.3(16/5-17/3):

16/5

An implementation that conforms to this Reference Manual shall support each capability required by the core language as specified. In addition, an implementation that conforms to this Reference Manual may conform to one or more Specialized Needs Annexes (or to none). Conformance to a Specialized Needs Annex means that each capability required by the Annex shall be provided as specified.

16.a

Discussion: The last sentence defines what it means to say that an implementation conforms to a Specialized Needs Annex, namely, only by supporting all capabilities required by the Annex.

17/3

An implementation conforming to this Reference Manual may provide additional aspects, attributes, library units, and pragmas. However, it shall not provide any aspect, attribute, library unit, or pragma having the same name as an aspect, attribute, library unit, or pragma (respectively) specified in a Specialized Needs Annex unless the provided construct is either as specified in the Specialized Needs Annex or is more limited in capability than that required by the Annex. A program that attempts to use an unsupported capability of an Annex shall either be identified by the implementation before run time or shall raise an exception at run time.

We propose to modify this wording to treat conformance to the annexes more on the same level as conformance to the core.  The two are now more independent of one another.

!recommendation

(See Summary.)

!wording

Replace RM 1.1.2(17) with the following:

Conformance is defined separately for the core language and each of the Specialized Needs Annexes (see 1.1.3).

Modify RM 1.1.3(16/5-17/3) as follows:

An implementation that conforms to [this]{the core of this} Reference Manual shall support each capability required by the core language {(see 1.1.2),} as specified. [In addition, an implementation that conforms to this Reference Manual may conform to one or more Specialized Needs Annexes (or to none). ] Conformance to a Specialized Needs Annex means that each capability required by the Annex shall be provided as specified.

An implementation conforming to this Reference Manual may provide additional aspects, attributes, library units, and pragmas. However, it shall not provide any aspect, attribute, library unit, or pragma having the same name as an aspect, attribute, library unit, or pragma (respectively) specified in {the core or} a Specialized Needs Annex unless the provided construct is either as specified in [the Specialized Needs Annex]{this Reference Manual} or is more limited in capability than that required by [the Annex]{this Reference Manual}. A program that attempts to use an unsupported capability [of an Annex] shall either be identified by the implementation before run time or shall raise an exception at run time.

!discussion

After reviewing other ISO standards, it seemed that there was no problem defining different levels of conformance. Therefore, we have tried to separate conformance to the “core” and the Specialized Needs Annexes, but generally treat them equivalently in terms of conformance, rather than making a special case of the core.

!ACATS test

Changing the status of Specialized Needed Annexes does not directly change any ACATS tests (ACATS tests can test optional requirements by the definition in ISO/IEC 18009). However, anything required of Ada implementations by the rewrite of the annexes may require existing tests to change their pass/fail criteria.

The ACATS currently treats the conformance of each annex separately, so the proposed changes would not have much impact on the ACATS. The ACATS does not attempt to test subsets of any part of the Reference Manual (either the core or the annexes), and that would not need to change with these changes. (It could change if there was sufficient interest and support, of course, but there would not be a requirement to find such support.)

!appendix