CVS difference for ai05s/ai05-0229-1.txt

--- ai05s/ai05-0229-1.txt	2011/11/01 05:32:53	1.23
+++ ai05s/ai05-0229-1.txt	2011/11/09 06:17:50	1.24
@@ -8279,6 +8279,113 @@
 
 ****************************************************************
 
+!topic Moving pragmas to Annex J (AI05-229)
+!reference J.15.3, J.15.5
+!from Adam Beneschan 11-06-22
+!discussion
+
+I realize I'm a little late to this party; I haven't been able to keep
+up with all the proposed language changes, and I wasn't aware of this
+AI until just now.  I apologize for not making these comments sooner. 
+
+I have some concerns about moving some of these pragmas to Annex J.
+I realize that it will still be legal to use them; however, putting
+them in a section called "obsolescent features" appears to give them
+"second-class" status, with the implication that their use is
+discouraged.  (J(1) actually says "not recommended".)  And I think in
+at least a couple cases, it's a mistake to give them that sort of
+status. 
+
+The cases I'm concerned about are Inline and Import (probably also
+Export and Convention).  When writing the specification of a package
+P, I've seen lots of cases where a subprogram is defined in the
+visible part of the package, and Inline appears in the private part.
+Although I don't think it affects the semantics in any way of a
+package that with's P, from a coding style standpoint I think it's a
+good idea to allow Inline in the private part.  The visible part
+should describe the characteristics of the package and its subprograms
+that the writer of a WITH'ing package would need to know about.  The
+fact that the subprogram is inlined is (in most cases) an
+implementation detail that is not important to the user of P.
+"Requiring" this implementation detail to appear in the visible part
+would clutter up the definition.  I'd think that moving this sort of
+implementation detail to the private part wherever possible ought to
+be encouraged, or at least not discouraged; but moving it to Annex J
+does discourage this, which I think is wrong.
+
+Similar comments apply to the Import pragma.  If a subprogram appears
+in the specification of P, but the implementor of P decides to
+implement it by importing it directly from a C library, that's an
+implementation detail that doesn't really belong in the visible part.
+In this case, the clutter seems worse because it will take three
+aspects (Import, Convention, External_Name) to specify the needed
+information. 
+
+There's a more serious problem with Import that I realized after I
+started writing this: if the External_Name or Link_Name involves a
+named string constant, using aspect clauses instead of Import will
+require this constant to be made visible, which might be undesirable.
+Example: 
+
+   package Interface_To_Some_C_Library is
+      ...
+      procedure Gyre (X : in out Slithy_Tove);
+      procedure Gimble (X : in out Slithy_Tove);
+      function Is_Mimsy (Obj : Borogove) return Boolean;
+
+   private
+      Prefix : constant String := "lc12_";
+      pragma Import (C, Gyre, Prefix & "gyre");
+      pragma Import (C, Gimble, Prefix & "gimble");
+      pragma Import (C, Is_Mimsy, Prefix & "mimsy");
+   end Interface_To_Some_C_Library;
+
+Using aspect clauses in this case would require moving the Prefix
+constant to the visible part of the package.  It should not be
+"required" to do this (or, more accurately, putting Prefix in the
+private part, which is certainly where it belongs, shouldn't be
+considered "not recommended").
+
+I haven't looked through the AI to see if there are other cases of
+pragmas being moved to Annex J that could have the same problem
+(i.e. causing implementation details that ought to be specifiable in a
+private part to be moved to the visible part).  
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 22, 2011  5:44 PM
+
+I don't believe that either Inline or Import should be hidden in the private part,
+because both have (subtle) semantic effects that potentially break privacy. In
+particular, inline adds dependencies that might make linking a program impossible. (I
+don't think inline should be allowed to do that, either, but that's the way it is.)
+Import usually requires parameters that also have convention C -- it's rarely possible
+to hide the *entire* thing.
+
+It's better to hide Import and all of the convention C stuff in a private package, and
+have the body of the Ada package call those routines (they can then fix up the Ada semantics
+at the same time). In that case, the private package is a C interface from the beginning and
+there is no reason to even think about hiding these things. It's unlikely that (especially
+if you want this to work with many Ada compilers, not just a specific one, because the only way
+to guarantee C-compatibility is with convention C) you can make calls directly without exposing
+the C-ness.
+
+Finally, the pragma syntax and semantics is *awful* for subprograms (remember all the renaming
+games that need to be played to make these work if there is any overloading), and the sooner
+people stop using them the better. If we *really* believe this is a real problem, we ought to
+find a way to allow aspects in the private part for subprograms (probably by allowing a repeated
+declaration with the "hidden" aspects).
+
+In any case, people can and will use the obsolescent pragmas. The same is true for
+attribute_definition_clauses (which we're not obsolescing because there are a few uses that cannot
+be done with aspects), but for most aspects (like size) you are better using aspects instead. (I've
+never believed in putting size clauses in the private part; that was the cause of many Ada language
+and Ada compiler bugs and never should have been allowed in the first place. We could have much
+simpler freezing rules if this sort of thing wasn't allowed.)
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Wednesday, July  6, 2011  6:11 PM