Inline Expansion of Subprograms

{AI05-0229-1} The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows:

Legality Rules

{AI05-0229-1} The pragma shall apply to one or more callable entities or generic subprograms.

Static Semantics

{AI05-0229-1} For If a pragma Inline applies to a callable entity or, this indicates that inline expansion is desired for all calls to that entity. If a pragma Inline applies to a generic subprogram, the following language-defined representation aspect may be specified: this indicates that inline expansion is desired for all calls to all instances of that generic subprogram.

The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram.

If directly specified, the aspect_definition shall be a static expression. [This aspect is never inherited;] if not directly specified, the aspect is False.

Aspect Description for Inline: For efficiency, Inline calls are requested for a subprogram.

This paragraph was deleted.Ramification: {AI05-0229-1} Note that inline expansion is desired no matter what name is used in the call. This allows one to request inlining for only one of several overloaded subprograms as follows:

This paragraph was deleted.package IO is
   procedure Put(X : in Integer);
   procedure Put(X : in String);
   procedure Put(X : in Character);
private
   procedure Character_Put(X : in Character) renames Put;
   pragma Inline(Character_Put);
end IO;

This paragraph was deleted.with IO; use IO;
procedure Main is
   I : Integer;
   C : Character;
begin
   ...
   Put(C); -- Inline expansion is desired.
   Put(I); -- Inline expansion is NOT desired.
end Main;

Ramification: {AI05-0229-1} The meaning of a subprogram can be changed by inline expansion as requested by aspect a pragma Inline only in the presence of failing checks (see 11.6).

Implementation Permissions

{AI05-0229-1} For each call, an implementation is free to follow or to ignore the recommendation determined expressed by the Inline aspect pragma.

Ramification: Note, in particular, that the recommendation cannot always be followed for a recursive call, and is often infeasible for entries. Note also that the implementation can inline calls even when no such desire was expressed via the Inline aspect by a pragma, so long as the semantics of the program remains unchanged.

{AI95-00309-01} {AI05-0229-1} An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part.

Reason: This is allowed for Ada 83 compatibility. This is only a permission as this usage is considered obsolescent.

Discussion: We only need to allow this in declarative_parts, because a body is only allowed in another body, and these all have declarative_parts.

7 {AI05-0229-1} The name in a pragma Inline can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities.

Incompatibilities With Ada 83

This paragraph was deleted. {AI95-00309-01} {AI05-0229-1} A pragma Inline cannot refer to a subprogram_body outside of that body. The pragma can be given inside of the subprogram body. Ada 2005 adds an Implementation Permission to allow this usage for compatibility (and Ada 95 implementations also can use this permission), but implementations do not have to allow such pragmas.

Extensions to Ada 83

This paragraph was deleted.{AI05-0229-1} A pragma Inline is allowed inside a subprogram_body if there is no corresponding subprogram_declaration. This is for uniformity with other program unit pragmas.

Extensions to Ada 95

This paragraph was deleted. {AI95-00309-01} {AI05-0229-1} Amendment Correction: Implementations are allowed to let Pragma Inline apply to a subprogram_body.

6.3.2 Inline Expansion of Subprograms