CVS difference for ais/ai-00199.txt
--- ais/ai-00199.txt 1998/09/30 00:17:36 1.1
+++ ais/ai-00199.txt 1999/03/30 00:33:14 1.2
@@ -1,4 +1,4 @@
-!standard 13.09 (03) 98-04-09 AI95-00199/01
+!standard 13.09 (03) 99-03-23 AI95-00199/02
!class binding interpretation 98-03-27
!status work item 98-04-02
!status received 98-03-27
@@ -7,19 +7,19 @@
!subject Pragma convention for a generic unit applies to its instances
Program unit pragmas that are not library-unit pragmas, when
applied to a generic unit, apply to its instances. This represents
a partial reversal of AI-00041.
Does pragma convention for a generic unit apply to instances? (Yes.)
-There are four language-defined program unit pragmas which are
+There are four language-defined program unit pragmas which are
not library-unit pragmas:
- pragma Inline
@@ -31,7 +31,7 @@
to a generic, should also apply to its instances. It concluded they
should not, in general, with pragma Inline as an exception, and
with the claim that pragmas Convention, Import, and Export (the
-interfacing pragmas) do not in any case apply to generics.
+interfacing pragmas) do not in any case apply to generics.
However, there is nothing precluding implementations from supporting
the interfacing pragmas for generic units. The natural interpretation
@@ -43,25 +43,32 @@
However, for program unit pragmas that are not library unit pragmas,
the most intuitive interpretation is that when applied to generic
program units, they are "inherited" by the instances of the generic.
-For each of the four language-defined non-library-unit program unit
+For each of the four language-defined non-library-unit program unit
pragmas, this rule makes sense, and it seems reasonable to assume
-that it would make sense for other similar pragmas. Of course, an
-implementation could always define a new "program-unit-ish" pragma
-for which it did not make sense, but implementations are allowed
-to define whatever semantics they choose for implementation-defined
+that it would make sense for other similar pragmas. Of course, an
+implementation could always define a new "program-unit-ish" pragma
+for which it did not make sense, but implementations are allowed
+to define whatever semantics they choose for implementation-defined
pragmas (subject to the usual recommendations about "good taste"
+Although a program unit pragma on a generic is "inherited"
+by its instances, it may be overridden by a pragma applied
+directly to the generic. This is analogous to the rule
+for inheriting representation items by a derived type from
+its parent type. The inherited specification may be overridden
+by a direct specification on the derived type itself.
AI-00041 includes a thorough analysis of all program-unit pragmas
-applicable to generic units other than the interfacing pragmas,
+applicable to generic units other than the interfacing pragmas,
and concludes that with the exception of pragma Inline, instances
should not inherit pragmas from generic units. However, if the
-program-unit pragmas are instead separated into two groups, those which
+program-unit pragmas are instead separated into two groups, those which
are library unit pragmas, and all others, it becomes more natural to
say that only library unit pragmas are not "inherited" by instances
(since of course the instances might not themselves be library units),
@@ -72,8 +79,14 @@
For those implementations that do support interfacing pragmas
on generics, it seems that the natural interpretation is for
the pragmas to be inherited by all instances.
+Even though we propose that non-library unit program unit pragmas be
+inherited by instances, we still want to allow overriding of
+such a pragma with one applied directly to the instance.
+Hence, even if a convention is specified on a generic,
+a pragma on a particular instance may override that convention.
!subject does pragma convention for a generic unit apply to instances?
Questions? Ask the ACAA Technical Agent