CVS difference for ais/ai-00367.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00367.txt

--- ais/ai-00367.txt	2004/04/06 19:57:17	1.2
+++ ais/ai-00367.txt	2004/04/06 22:43:32	1.3
@@ -1,27 +1,88 @@
-!standard 10.2.1                                     04-02-04   AI95-00367/00
+!standard 10.2.1                                     04-04-02   AI95-00367/01
 !class amendment 03-12-07
 !status No Action (10-0-0) 04-03-05
 !status work item 03-12-07
 !status received 03-12-07
 !priority Low
 !difficulty Easy
-!subject Include type declarations for Natural and Positive in Package Interfaces
+!subject Add subtype declarations for Natural_n and Positive_n in package Interfaces
+Add subtype declarations for Natural_n and Positive_n in package Interfaces.
+Our use of Ada uncovered a series of type declarations that we would like
+to see standardized in the language. The Ada 95 update to the language
+provided specifically sized implementations of Integer and Unsigned (i.e.,
+Interfaces.Integer_8, Interfaces.Unsigned_16). However, the same was not
+done for the Positive or Natural subtypes of Integer.
+We would like to propose that the standard incorporate the following
+definitions into the predefined Interfaces package.
+(See problem.)
+As explained in B.2(1), these types were introduced in Ada 95 because they are
+generally useful for interfacing with other languages (including assembly)
+and/or with hardware. Their main characteristic is that they correspond to
+formats directly supported by the target hardware (see RM95 B.2(8)). In
+particular, they are the only types in the language for which rotating and
+shifting subprograms are available. From this perspective, Natural_n and
+Positive_n subtypes are not particularly relevant, since the corresponding
+hardware operations and formats generally don't have any equivalent to Ada
+While they can be used as such, the types in Interfaces are _not_ intended to
+replace user-defined types or subtypes for general usage. At any rate, if in a
+particular situation there is a need for the Natural_n and Positive_n subtypes,
+it's very easy for the user to declare their own (possibly in a child of
+Interfaces, if appropriate).
+Furthermore there is a compatibility issue with adding new declarations to
+existing predefined units. In the presence of use clauses, existing code might
+become ambiguous if it happens to use the same identifiers. Of course, there is
+a judgment call as to whether a given identifier is likely to cause conflict or
+not. In this instance, chances are that there are projects out there that use
+the names Positive_n and Natural_n, so it seems that conflicts are quite likely.
+To summarize:
+1 - The implementation cost is close to zero.
+2 - The user benefit is close to zero as these types were specifically intended
+for interfacing, an area where subtypes are not terribly useful.
+3 - The users who actually need these subtypes have probably defined them years
+ago anyway.
+4 - There is a substantial risk of introducing incompatibilities.
+Based on this analysis, this AI is classed as No Action.
 !ACATS test
+None needed.

Questions? Ask the ACAA Technical Agent