Re: Should Inline be private in the private part of a package spec?

[Adam Beneschan <adam@irvine.com>]

On Friday, August 3, 2012 6:30:50 AM UTC-7, Georg Bauhaus wrote:
> The aspect notation of Ada 2012 lets me specify Inline as
> an aspect giving a pragmatic hint to the compiler.
> This hint is very near the declaration:
> 
> package P is
> 
>   procedure Op (X : T)
>     with Inline;
> 
> end P;
> 
> Should the readers of a package spec be bothered with hints
> to the compiler if these hints address optimization, or other
> aspect of how to implement a subprogram?
> 
> The hint does not add to an understanding of what an operation
> is to achieve, IMHO. This understanding is what I'd hope to
> get from reading a spec. Alternatively,
> 
> package P is
>
>   procedure Op (X : T);
>
> private
>   pragma Inline (Op);
> end P;
> 
> still lets the reader take note of inlining, should they
> be so inclined. Am I missing something?

I share your concern.  I sent something to Ada-Comment about this in June 2011, expressing this concern about making the pragmas "obsolescent"; here's part of Randy's response:

# 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 . . .

Randy also thought it was better to encourage people to stop using the pragmas because using the pragmas on overloaded subprograms is problematic.  (And GNAT doesn't always get it right.  There are several examples of publicly available code that contain illegal Import pragmas on overloaded routines that GNAT didn't catch.  Another reason, I suppose, not to use them.)

Anyway, while I'm with you that I don't want a reader to have to see stuff like this in the package spec, at least Ada is still way ahead of, say, Java or C# in that regard; if I'm not confused, you have to put the whole body of the function right by the point where it's first declared, not just a small hint to the compiler.  Also, since we now have GUIs to work with programs instead of just punch cards and printouts, it's easy to envision a GUI displaying "compiler hints" like this in a lighter color, so that a reader looking at the package spec  because he wants to know how to use the package can focus on the important parts.

                        -- Adam