ARG-Editor
commented
1 year ago My thoughts on this issue:
The original proposal was left unfinished in part because standards are replaced, not additive. Therefore, we cannot talk about previous editions of the standard within the wording of the current standard.
That problem can be worked around by explicitly giving the values of the aspect in each unit defined in the language definition (rather than just saying that they apply to the entities first defined in that edition). That's clearly more work, but it is a one-time expense (since those edition aspects never change). One also would need to add the aspect to the handful of routines added in later editions (such as those added into the Ada.Strings family).
Note that defining an identifier like Ada_2005 is acceptable, so long as we don't use a reference to the previous version of the standard. It should be fine to define an Ada_2005 identifier and apply it to the packages and subprograms added in Ada 2005.
There also was some confusion about the difference between Implementation_Defined and Third_Party_Defined entities. Some libraries are provided with compilers but are independent from those compilers; those sorts of reusable units should be identified as Third_Party_Defined. For instance, Claw is provided with some versions of Janus/Ada, but it is available for other compilers as well as Janus/Ada. So it is best identified as a Third_Party_Defined library. That would be the case for any reusable code intended for use with multiple compilers and/or projects. The actual owner of the library does not matter. (Perhaps there is a better name for this concept?)
An implementation of the AI12-0018-1 proposal exists. The Janus/Ada compiler implements this mechanism to provide versioning capabilities. (It doesn't implement the restriction pragmas at this time (or any restriction pragmas), but it does support similar compiler options and a full set of warnings.) All of the supported Ada language-defined units were annotated with this aspect, including all of the individual added subprograms in packages like Ada.Strings.Fixed.
The original proposal in AI12-0018-1 needs to replace Ada_2020 with Ada_2022, but of course that is a trivial change. Note that the restriction No_Implementation_Defined_Entities is slightly broader than the existing restrictions, since it includes top-level packages like GNAT for the Gnat implementation.
The main remaining question is whether Ada users would find the restrictions pragmas valuable enough to properly define these as part of the Standard. We're posting this as an issue in part to get some feedback on that.
Randy.
jprosen
sttaft
Richard-Wai
This issue continues an unfinished issue from Ada 2022 (in this case, AI12-0018-1). This issue was created to fulfill the ARG resolution of November 10, 2022.
Each edition of the Ada standard adds new entities, sometimes to existing Ada packages. When creating portable programs, users want to be able to avoid use of newer entities in their program (in order to use the program on the maximum number of compilers).
Most Ada implementations provide some mechanism for determining the edition of Ada that is being supported. Ironically, these mechanisms themselves pose a portability problem, since everyone's is different.
Ada 2012 includes a set of restrictions for implementation-defined entities, but these are limited to various places where the Ada language specifically allows implementation-defined variations. In particular, compilation units defined outside of the language-defined hierarchies are not included. For instance, package GNAT for the GNAT implementation is not covered by the language-defined restriction, nor are the many packages still retained for Ada 83 compatibility in implementations that existed for Ada 83.
AI12-0018-1 proposes an aspect to specify the edition of code (including of user-defined code) and series of restrictions to select sets of that code.