17. GNAT language extensions

The GNAT compiler implements a certain number of language extensions on top of the latest Ada standard, implementing its own extended superset of Ada.

There are two sets of language extensions:

  • The first is the curated set. The features in that set are features that we consider being worthy additions to the Ada language, and that we want to make available to users early on.

  • The second is the experimental set. It includes the first, but also experimental features, which are considered experimental because they’re still in an early prototyping phase. These features might be removed or heavily modified at any time.

17.1. How to activate the extended GNAT Ada superset

There are two ways to activate the extended GNAT Ada superset:

pragma Extensions_Allowed (On)

As a configuration pragma, you can either put it at the beginning of a source file, or in a .adc file corresponding to your project.

  • The -gnatX command-line option will activate the curated subset of extensions.

Attention

You can activate the experimental set of extensions in addition by using either the -gnatX0 command-line option, or the pragma Extensions_Allowed with All_Extensions as an argument. However, it is not recommended you use this subset for serious projects; it is only meant as a technology preview for use in playground experiments.

17.2. Curated Extensions

Features activated via -gnatX or pragma Extensions_Allowed (On).

17.2.1. Local Declarations Without Block

A basic_declarative_item may appear at the place of any statement. This avoids the heavy syntax of block_statements just to declare something locally.

The only valid kinds of declarations for now are object_declaration, object_renaming_declaration, use_package_clause, and use_type_clause.

For example:

if X > 5 then
   X := X + 1;

   Squared : constant Integer := X**2;

   X := X + Squared;
end if;

It is generally a good practice to declare local variables (or constants) with as short a lifetime as possible. However, introducing a declare block to accomplish this is a relatively heavy syntactic load along with a traditional extra level of indentation. The alternative syntax supported here allows declarations in any statement sequence. The lifetime of such local declarations is until the end of the enclosing construct. The same enclosing construct cannot contain several declarations of the same defining name; however, overriding symbols from higher-level scopes works similarly to the explicit declare block.

If the enclosing construct allows an exception handler (such as an accept statement, begin-except-end block or a subprogram body), declarations that appear at the place of a statement are not visible within the handler. Only declarations that precede the beginning of the construct with an exception handler would be visible in this handler.

Attention

Here are a couple of examples illustrating the scoping rules described above.

  1. Those declarations are not visible from the potential exception handler:

    begin
   A : Integer
   ...
exception
   when others =>
       Put_Line (A'Image) --  ILLEGAL
end;

  2. The following is legal

    declare
   A : Integer := 10;
begin
   A : Integer := 12;
end;

    because it is roughly expanded into

      declare
     A : Integer := 10;
  begin
     declare
        A : Integer := 12;
     begin
        ...
     end;
  end;

And as such the second ``A`` declaration is hiding the first one.

17.2.2. Deep delta Aggregates

Ada 2022’s delta aggregates are extended to allow deep updates.

A delta aggregate may be used to specify new values for subcomponents of the copied base value, instead of only new values for direct components of the copied base value. This allows a more compact expression of updated values with a single delta aggregate, instead of multiple nested delta aggregates.

The syntax of delta aggregates in the extended version is the following:

17.2.2.1. Syntax

delta_aggregate ::= record_delta_aggregate | array_delta_aggregate

record_delta_aggregate ::=
  ( base_expression with delta record_subcomponent_association_list )

record_subcomponent_association_list ::=
  record_subcomponent_association {, record_subcomponent_association}

record_subcomponent_association ::=
  record_subcomponent_choice_list => expression

record_subcomponent_choice_list ::=
  record_subcomponent_choice {'|' record_subcomponent_choice}

record_subcomponent_choice ::=
    component_selector_name
  | record_subcomponent_choice (expression)
  | record_subcomponent_choice . component_selector_name

array_delta_aggregate ::=
    ( base_expression with delta array_component_association_list )
  | '[' base_expression with delta array_component_association_list ']'
  | ( base_expression with delta array_subcomponent_association_list )
  | '[' base_expression with delta array_subcomponent_association_list ']'

array_subcomponent_association_list ::=
  array_subcomponent_association {, array_subcomponent_association}

array_subcomponent_association ::=
  array_subcomponent_choice_list => expression

array_subcomponent_choice_list ::=
  array_subcomponent_choice {'|' array_subcomponent_choice}

array_subcomponent_choice ::=
    ( expression )
  | array_subcomponent_choice (expression)
  | array_subcomponent_choice . component_selector_name

17.2.2.2. Legality Rules

  1. For an array_delta_aggregate, the discrete_choice shall not be others.

  2. For an array_delta_aggregate, the dimensionality of the type of the delta_aggregate shall be 1.

  3. For an array_delta_aggregate, the base_expression and each expression in every array_component_association or array_subcomponent_association shall be of a nonlimited type.

  4. For a record_delta_aggregate, no record_subcomponent_choices that consists of only component_selector_names shall be the same or a prefix of another record_subcomponent_choice.

  5. For an array_subcomponent_choice or a record_subcomponent_choice the component_selector_name shall not be a subcomponent that depends on discriminants of an unconstrained record subtype with defaulted discriminants unless its prefix consists of only component_selector_names.

    [Rationale: As a result of this rule, accessing the subcomponent can only lead to a discriminant check failure if the subcomponent was not present in the object denoted by the base_expression, prior to any update.]

17.2.2.3. Dynamic Semantics

The evaluation of a delta_aggregate begins with the evaluation of the base_expression of the delta_aggregate; then that value is used to create and initialize the anonymous object of the aggregate. The bounds of the anonymous object of an array_delta_aggregate and the discriminants (if any) of the anonymous object of a record_delta_aggregate are those of the base_expression.

If a record_delta_aggregate is of a specific tagged type, its tag is that of the specific type; if it is of a class-wide type, its tag is that of the base_expression.

For a delta_aggregate, for each discrete_choice or each subcomponent associated with a record_subcomponent_associated, array_component_association or array_subcomponent_association (in the order given in the enclosing discrete_choice_list or subcomponent_association_list, respectively):

  • if the associated subcomponent belongs to a variant, a check is made that the values of the governing discriminants are such that the anonymous object has this component. The exception Constraint_Error is raised if this check fails.

  • if the associated subcomponent is a subcomponent of an array, then for each represented index value (in ascending order, if the discrete_choice represents a range):

    • the index value is converted to the index type of the array type.

    • a check is made that the index value belongs to the index range of the corresponding array part of the anonymous object; Constraint_Error is raised if this check fails.

    • the expression of the record_subcomponent_association, array_component_association or array_subcomponent_association is evaluated, converted to the nominal subtype of the associated subcomponent, and assigned to the corresponding subcomponent of the anonymous object.

17.2.2.4. Examples

 1declare
 2   type Point is record
 3      X, Y : Integer;
 4   end record;
 5
 6   type Segment is array (1 .. 2) of Point;
 7   type Triangle is array (1 .. 3) of Segment;
 8
 9   S : Segment := (1 .. 2 => (0, 0));
10   T : Triangle := (1 .. 3 => (1 .. 2 => (0, 0)));
11begin
12   S := (S with delta (1).X | (2).Y => 12, (1).Y => 15);
13
14   pragma Assert (S (1).X = 12);
15   pragma Assert (S (2).Y = 12);
16   pragma Assert (S (1).Y = 15);
17
18   T := (T with delta (2)(1).Y => 18);
19   pragma Assert (T (2)(1).Y = 18);
20end;

17.2.3. Fixed lower bounds for array types and subtypes

Unconstrained array types and subtypes can be specified with a lower bound that is fixed to a certain value, by writing an index range that uses the syntax <lower-bound-expression> .. <>. This guarantees that all objects of the type or subtype will have the specified lower bound.

For example, a matrix type with fixed lower bounds of zero for each dimension can be declared by the following:

type Matrix is
  array (Natural range 0 .. <>, Natural range 0 .. <>) of Integer;

Objects of type Matrix declared with an index constraint must have index ranges starting at zero:

M1 : Matrix (0 .. 9, 0 .. 19);
M2 : Matrix (2 .. 11, 3 .. 22);  -- Warning about bounds; will raise CE

Similarly, a subtype of String can be declared that specifies the lower bound of objects of that subtype to be 1:

subtype String_1 is String (1 .. <>);

If a string slice is passed to a formal of subtype String_1 in a call to a subprogram S, the slice’s bounds will “slide” so that the lower bound is 1.

Within S, the lower bound of the formal is known to be 1, so, unlike a normal unconstrained String formal, there is no need to worry about accounting for other possible lower-bound values. Sliding of bounds also occurs in other contexts, such as for object declarations with an unconstrained subtype with fixed lower bound, as well as in subtype conversions.

Use of this feature increases safety by simplifying code, and can also improve the efficiency of indexing operations, since the compiler statically knows the lower bound of unconstrained array formals when the formal’s subtype has index ranges with static fixed lower bounds.

17.2.4. Prefixed-view notation for calls to primitive subprograms of untagged types

When operating on an untagged type, if it has any primitive operations, and the first parameter of an operation is of the type (or is an access parameter with an anonymous type that designates the type), you may invoke these operations using an object.op(...) notation, where the parameter that would normally be the first parameter is brought out front, and the remaining parameters (if any) appear within parentheses after the name of the primitive operation.

This same notation is already available for tagged types. This extension allows for untagged types. It is allowed for all primitive operations of the type independent of whether they were originally declared in a package spec, or were inherited and/or overridden as part of a derived type declaration occurring anywhere, so long as the first parameter is of the type, or an access parameter designating the type.

For example:

generic
   type Elem_Type is private;
package Vectors is
    type Vector is private;
    procedure Add_Element (V : in out Vector; Elem : Elem_Type);
    function Nth_Element (V : Vector; N : Positive) return Elem_Type;
    function Length (V : Vector) return Natural;
private
    function Capacity (V : Vector) return Natural;
       --  Return number of elements that may be added without causing
       --  any new allocation of space

    type Vector is ...
      with Type_Invariant => Vector.Length <= Vector.Capacity;
    ...
end Vectors;

package Int_Vecs is new Vectors(Integer);

V : Int_Vecs.Vector;
...
V.Add_Element(42);
V.Add_Element(-33);

pragma Assert (V.Length = 2);
pragma Assert (V.Nth_Element(1) = 42);

17.2.5. Expression defaults for generic formal functions

The declaration of a generic formal function is allowed to specify an expression as a default, using the syntax of an expression function.

Here is an example of this feature:

generic
   type T is private;
   with function Copy (Item : T) return T is (Item); -- Defaults to Item
package Stacks is

   type Stack is limited private;

   procedure Push (S : in out Stack; X : T); -- Calls Copy on X
   function Pop (S : in out Stack) return T; -- Calls Copy to return item

private
   -- ...
end Stacks;

If Stacks is instantiated with an explicit actual for Copy, then that will be called when Copy is called in the generic body. If the default is used (i.e. there is no actual corresponding to Copy), then calls to Copy in the instance will simply return Item.

17.2.6. String interpolation

The syntax for string literals is extended to support string interpolation. An interpolated string literal starts with f, immediately before the first double-quote character.

Within an interpolated string literal, an arbitrary expression, when enclosed in { ... }, is expanded at run time into the result of calling 'Image on the result of evaluating the expression enclosed by the brace characters, unless it is already a string or a single character.

Here is an example of this feature where the expressions Name and X + Y will be evaluated and included in the string.

procedure Test_Interpolation is
   X    : Integer := 12;
   Y    : Integer := 15;
   Name : String := "Leo";
begin
   Put_Line (f"The name is {Name} and the sum is {X + Y}.");
end Test_Interpolation;

This will print:

The name is Leo and the sum is 27.

In addition, an escape character (\) is provided for inserting certain standard control characters (such as \t for tabulation or \n for newline) or to escape characters with special significance to the interpolated string syntax, namely ", {, },and \ itself.

escaped_character

meaning

\a

ALERT

\b

BACKSPACE

\f

FORM FEED

\n

LINE FEED

\r

CARRIAGE RETURN

\t

CHARACTER TABULATION

\v

LINE TABULATION

\0

NUL

\\

\

\"

"

\{

{

\}

}

Note that, unlike normal string literals, doubled double-quote characters have no special significance. So to include a double-quote or a brace character in an interpolated string, they must be preceded by a \. Multiple interpolated strings are concatenated. For example:

Put_Line
  (f"X = {X} and Y = {Y} and X+Y = {X+Y};\n" &
   f" a double quote is \" and" &
   f" an open brace is \{");

This will print:

X = 12 and Y = 15 and X+Y = 27
a double quote is " and an open brace is {

17.2.7. Constrained attribute for generic objects

The Constrained attribute is permitted for objects of generic types. The result indicates whether the corresponding actual is constrained.

17.2.8. Static aspect on intrinsic functions

The Ada 202x Static aspect can be specified on Intrinsic imported functions and the compiler will evaluate some of these intrinsics statically, in particular the Shift_Left and Shift_Right intrinsics.

17.2.9. First Controlling Parameter

A new pragma/aspect, First_Controlling_Parameter, is introduced for tagged types, altering the semantics of primitive/controlling parameters. When a tagged type is marked with this aspect, only subprograms where the first parameter is of that type will be considered dispatching primitives. This pragma/aspect applies to the entire hierarchy, starting from the specified type, without affecting inherited primitives.

Here is an example of this feature:

package Example is
   type Root is tagged private;

   procedure P (V : Integer; V2 : Root);
   -- Primitive

   type Child is tagged private
     with First_Controlling_Parameter;

private
   type Root is tagged null record;
   type Child is new Root with null record;

   overriding
   procedure P (V : Integer; V2 : Child);
   -- Primitive

   procedure P2 (V : Integer; V2 : Child);
   -- NOT Primitive

   function F return Child; -- NOT Primitive

   function F2 (V : Child) return Child;
   -- Primitive, but only controlling on the first parameter
end Example;

Note that function F2 (V : Child) return Child; differs from F2 (V : Child) return Child'Class; in that the return type is a specific, definite type. This is also distinct from the legacy semantics, where further derivations with added fields would require overriding the function.

The option -gnatw_j, that you can pass to the compiler directly, enables warnings related to this new language feature. For instance, compiling the example above without this switch produces no warnings, but compiling it with -gnatw_j generates the following warning on the declaration of procedure P2:

warning: not a dispatching primitive of tagged type "Child"
warning: disallowed by First_Controlling_Parameter on "Child"

For generic formal tagged types, you can specify whether the type has the First_Controlling_Parameter aspect enabled:

generic
   type T is tagged private with First_Controlling_Parameter;
package T is
    type U is new T with null record;
    function Foo return U; -- Not a primitive
end T;

For tagged partial views, the value of the aspect must be consistent between the partial and full views:

package R is
   type T is tagged private;
...
private
   type T is tagged null record with First_Controlling_Parameter; -- ILLEGAL
end R;

Restricting the position of controlling parameter offers several advantages:

  • Simplification of the dispatching rules improves readability of Ada programs. One doesn’t need to analyze all subprogram parameters to understand if the given subprogram is a primitive of a certain tagged type.

  • A programmer is free to use any type, including class-wide types, on other parameters of a subprogram, without the need to consider possible effects of overriding a primitive or creating new one.

  • The result of a function is never a controlling result.

17.2.10. Unsigned_Base_Range aspect

A new pragma/aspect, Unsigned_Base_Range, is introduced to explicitly enforce the use of an unsigned base type for signed integer types. RM-3.5.4(9) mandates a symmetric base range for signed integer types. This requirement often requires the use of larger data types for arithmetic operations, potentially introducing undesirable run-time overhead and performance penalties, particularly in embedded systems. For instance, on a 64-bit architecture, a 64-bit multiplication can be performed with a single hardware instruction, whereas a 128-bit multiplication requires multiple instructions and intermediate steps.

Here is an example of this feature:

type Uns_64 is range 0 .. 2 ** 64 - 1
  with Size => 64,
       Unsigned_Base_Range => True;

It ensures that arithmetic operations of type Uns_64 are carried out using 64 bits.

17.2.11. Generalized Finalization

The Finalizable aspect can be applied to any record type, tagged or not, to specify that it provides the same level of control on the operations of initialization, finalization, and assignment of objects as the controlled types (see RM 7.6(2) for a high-level overview). The only restriction is that the record type must be a root type, in other words not a derived type.

The aspect additionally makes it possible to specify relaxed semantics for the finalization operations by means of the Relaxed_Finalization setting. Here is the archetypal example:

type T is record
  ...
end record
  with Finalizable => (Initialize           => Initialize,
                       Adjust               => Adjust,
                       Finalize             => Finalize,
                       Relaxed_Finalization => True);

procedure Adjust     (Obj : in out T);
procedure Finalize   (Obj : in out T);
procedure Initialize (Obj : in out T);

The three procedures have the same profile, with a single in out parameter, and also have the same dynamic semantics as for controlled types:

  • Initialize is called when an object of type T is declared without initialization expression.

  • Adjust is called after an object of type T is assigned a new value.

  • Finalize is called when an object of type T goes out of scope (for stack-allocated objects) or is deallocated (for heap-allocated objects). It is also called when the value is replaced by an assignment.

However, when Relaxed_Finalization is either True or not explicitly specified, the following differences are implemented relative to the semantics of controlled types:

  • The compiler has permission to perform no automatic finalization of heap-allocated objects: Finalize is only called when such an object is explicitly deallocated, or when the designated object is assigned a new value. As a consequence, no runtime support is needed for performing implicit deallocation. In particular, no per-object header data is needed for heap-allocated objects.

    Heap-allocated objects allocated through a nested access type will therefore not be deallocated either. The result is simply that memory will be leaked in this case.

  • The Adjust and Finalize procedures are automatically considered as having the No_Raise aspect specified for them. In particular, the compiler has permission to enforce none of the guarantees specified by the RM 7.6.1 (14/1) and subsequent subclauses.

Simple example of ref-counted type:

type T is record
   Value     : Integer;
   Ref_Count : Natural := 0;
end record;

procedure Inc_Ref (X : in out T);
procedure Dec_Ref (X : in out T);

type T_Access is access all T;

type T_Ref is record
   Value : T_Access;
end record
   with Finalizable => (Adjust   => Adjust,
                        Finalize => Finalize);

procedure Adjust (Ref : in out T_Ref) is
begin
   Inc_Ref (Ref.Value);
end Adjust;

procedure Finalize (Ref : in out T_Ref) is
begin
   Def_Ref (Ref.Value);
end Finalize;

Simple file handle that ensures resources are properly released:

package P is
   type File (<>) is limited private;

   function Open (Path : String) return File;

   procedure Close (F : in out File);

private
   type File is limited record
      Handle : ...;
   end record
      with Finalizable (Finalize => Close);
end P;

17.2.11.1. Finalizable tagged types

The aspect is inherited by derived types and the primitives may be overridden by the derivation. The compiler-generated calls to these operations are then dispatching whenever it makes sense, i.e. when the object in question is of a class-wide type and the class includes at least one finalizable tagged type.

17.2.11.2. Composite types

When a finalizable type is used as a component of a composite type, the latter becomes finalizable as well. The three primitives are derived automatically in order to call the primitives of their components. The dynamic semantics is the same as for controlled components of composite types.

17.2.11.3. Interoperability with controlled types

Finalizable types are fully interoperable with controlled types, in particular it is possible for a finalizable type to have a controlled component and vice versa, but the stricter dynamic semantics, in other words that of controlled types, is applied in this case.

17.3. Experimental Language Extensions

Features activated via -gnatX0 or pragma Extensions_Allowed (All_Extensions).

17.3.1. Conditional when constructs

This feature extends the use of when as a way to condition a control-flow related statement, to all control-flow related statements.

To do a conditional return in a procedure the following syntax should be used:

procedure P (Condition : Boolean) is
begin
   return when Condition;
end P;

This will return from the procedure if Condition is true.

When being used in a function the conditional part comes after the return value:

function Is_Null (I : Integer) return Boolean is
begin
   return True when I = 0;
   return False;
end;

In a similar way to the exit when a goto ... when can be employed:

procedure Low_Level_Optimized is
   Flags : Bitmapping;
begin
   Do_1 (Flags);
   goto Cleanup when Flags (1);

   Do_2 (Flags);
   goto Cleanup when Flags (32);

   --  ...

<<Cleanup>>
   --  ...
end;

To use a conditional raise construct:

procedure Foo is
begin
   raise Error when Imported_C_Func /= 0;
end;

An exception message can also be added:

procedure Foo is
begin
   raise Error with "Unix Error"
     when Imported_C_Func /= 0;
end;

17.3.2. Implicit With

This feature allows a standalone use clause in the context clause of a compilation unit to imply an implicit with of the same library unit where an equivalent with clause would be allowed.

use Ada.Text_IO;
procedure Main is
begin
   Put_Line ("Hello");
end;

17.3.3. Storage Model

This extends Storage Pools into a more efficient model allowing higher performance, easier integration with low footprint embedded run-times and copying data between different pools of memory. The latter is especially useful when working with distributed memory models, in particular to support interactions with GPU.

17.3.3.1. Aspect Storage_Model_Type

A Storage model is a type with a specified Storage_Model_Type aspect, e.g.:

type A_Model is null record
   with Storage_Model_Type (...);

Storage_Model_Type itself accepts six parameters:

  • Address_Type, the type of the address managed by this model. This has to be a scalar type or derived from System.Address.

  • Allocate, a procedure used for allocating memory in this model

  • Deallocate, a procedure used for deallocating memory in this model

  • Copy_To, a procedure used to copy memory from native memory to this model

  • Copy_From, a procedure used to copy memory from this model to native memory

  • Storage_Size, a function returning the amount of memory left

  • Null_Address, a value for the null address value

By default, Address_Type is System.Address, and the five subprograms perform native operations (e.g. the allocator is the native new allocator). Users can decide to specify one or more of these. When an Address_Type is specified to be other than System.Address, all of the subprograms have to be specified.

The prototypes of these procedures are as follows:

procedure Allocate
  (Model           : in out A_Model;
   Storage_Address : out Address_Type;
   Size            : Storage_Count;
   Alignment       : Storage_Count);

procedure Deallocate
  (Model           : in out A_Model;
   Storage_Address : out Address_Type;
   Size            : Storage_Count;
   Alignment       : Storage_Count);

procedure Copy_To
  (Model   : in out A_Model;
   Target  : Address_Type;
   Source  : System.Address;
   Size    : Storage_Count);

procedure Copy_From
  (Model  : in out A_Model;
   Target : System.Address;
   Source : Address_Type;
   Size   : Storage_Count);

function Storage_Size
  (Pool : A_Model)
   return Storage_Count;

Here’s an example of how this could be instantiated in the context of CUDA:

package CUDA_Memory is

   type CUDA_Storage_Model is null record
      with Storage_Model_Type => (
         Address_Type => CUDA_Address,
         Allocate     => CUDA_Allocate,
         Deallocate   => CUDA_Deallocate,
         Copy_To      => CUDA_Copy_To,
         Copy_From    => CUDA_Copy_From,
         Storage_Size => CUDA_Storage_Size,
         Null_Address => CUDA_Null_Address
      );

   type CUDA_Address is new System.Address;
   --  We're assuming for now same address size on host and device

   procedure CUDA_Allocate
     (Model           : in out CUDA_Storage_Model;
      Storage_Address : out CUDA_Address;
      Size            : Storage_Count;
      Alignment       : Storage_Count);

   procedure CUDA_Deallocate
     (Model           : in out CUDA_Storage_Model;
      Storage_Address : out CUDA_Address;
      Size            : Storage_Count;
      Alignment       : Storage_Count);

   procedure CUDA_Copy_To
     (Model  : in out CUDA_Storage_Model;
      Target : CUDA_Address;
      Source : System.Address;
      Size   : Storage_Count);

   procedure CUDA_Copy_From
     (Model   : in out CUDA_Storage_Model;
      Target  : System.Address;
      Source  : CUDA_Address;
      Size    : Storage_Count);

   function CUDA_Storage_Size
     (Pool : CUDA_Storage_Model)
      return Storage_Count return Storage_Count'Last;

   CUDA_Null_Address : constant CUDA_Address :=
      CUDA_Address (System.Null_Address);

   CUDA_Memory : CUDA_Storage_Model;

end CUDA_Memory;

17.3.3.2. Aspect Designated_Storage_Model

A new aspect, Designated_Storage_Model, allows to specify the memory model for the objects pointed by an access type. Under this aspect, allocations and deallocations will come from the specified memory model instead of the standard ones. In addition, if write operations are needed for initialization, or if there is a copy of the target object from and to a standard memory area, the Copy_To and Copy_From functions will be called. It allows to encompass the capabilities of storage pools, e.g.:

procedure Main is
   type Integer_Array is array (Integer range <>) of Integer;

   type Host_Array_Access is access all Integer_Array;
   type Device_Array_Access is access Integer_Array
      with Designated_Storage_Model => CUDA_Memory;

   procedure Free is new Unchecked_Deallocation
      (Host_Array_Type, Host_Array_Access);
   procedure Free is new Unchecked_Deallocation
      (Device_Array_Type, Device_Array_Access);

   Host_Array : Host_Array_Access := new Integer_Array (1 .. 10);

   Device_Array : Device_Array_Access := new Host_Array (1 .. 10);
   --  Calls CUDA_Storage_Model.Allocate to allocate the fat pointers and
   --  the bounds, then CUDA_Storage_Model.Copy_In to copy the values of the
   --  boundaries.
begin
   Host_Array.all := (others => 0);

   Device_Array.all := Host_Array.all;
   --  Calls CUDA_Storage_Model.Copy_To to write to the device array from the
   --  native memory.

   Host_Array.all := Device_Array.all;
   --  Calls CUDA_Storage_Model.Copy_From to read from the device array and
   --  write to native memory.

   Free (Host_Array);

   Free (Device_Array);
   --  Calls CUDA_Storage_Model.Deallocate;
end;

Taking 'Address of an object with a specific memory model returns an object of the type of the address for that memory category, which may be different from System.Address.

When copying is performed between two specific memory models, the native memory is used as a temporary between the two. E.g.:

type Foo_I is access Integer with Designated_Storage_Model => Foo;
type Bar_I is access Integer with Designated_Storage_Model => Bar;

  X : Foo_I := new Integer;
  Y : Bar_I := new Integer;
begin
  X.all := Y.all;

conceptually becomes:

  X : Foo_I := new Integer;
  T : Integer;
  Y : Bar_I := new Integer;
begin
  T := Y.all;
  X.all := T;

17.3.3.3. Legacy Storage Pools

Legacy Storage Pools are now replaced by a Storage_Model_Type. They are implemented as follows:

type Root_Storage_Pool is abstract
  new Ada.Finalization.Limited_Controlled with private
with Storage_Model_Type => (
   Allocate     => Allocate,
   Deallocate   => Deallocate,
   Storage_Size => Storage_Size
);
pragma Preelaborable_Initialization (Root_Storage_Pool);

procedure Allocate
  (Pool                     : in out Root_Storage_Pool;
   Storage_Address          : out System.Address;
   Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
   Alignment                : System.Storage_Elements.Storage_Count)
is abstract;

procedure Deallocate
  (Pool                     : in out Root_Storage_Pool;
   Storage_Address          : System.Address;
   Size_In_Storage_Elements : System.Storage_Elements.Storage_Count;
   Alignment                : System.Storage_Elements.Storage_Count)
is abstract;

function Storage_Size
  (Pool : Root_Storage_Pool)
   return System.Storage_Elements.Storage_Count
is abstract;

The legacy notation:

type My_Pools is new Root_Storage_Pool with record [...]

My_Pool_Instance : Storage_Model_Pool.Storage_Model :=
   My_Pools'(others => <>);

type Acc is access Integer_Array with Storage_Pool => My_Pool;

can still be accepted as a shortcut for the new syntax.

17.3.4. Attribute Super

The Super attribute can be applied to objects of tagged types in order to obtain a view conversion to the most immediate specific parent type.

It cannot be applied to objects of types without any ancestors.

type T1 is tagged null record;
procedure P (V : T1);

type T2 is new T1 with null record;

type T3 is new T2 with null record;
procedure P (V : T3);

procedure Call (
  V1 : T1'Class;
  V2 : T2'Class;
  V3 : T3'Class) is
begin
  V1'Super.P; --  Illegal call as T1 doesn't have any ancestors
  V2'Super.P; --  Equivalent to "T1 (V).P;", a non-dispatching call
              --  to T1's primitive procedure P.
  V3'Super.P; --  Equivalent to "T2 (V).P;"; Since T2 doesn't
              --  override P, a non-dispatching call to T1.P is
              --  executed.
end;

17.3.5. Simpler Accessibility Model

The goal of this feature is to simplify the accessibility rules by removing dynamic accessibility checks that are often difficult to understand and debug. The new rules eliminate the need for runtime accessibility checks by imposing more conservative legality rules when enabled via a new restriction (see RM 13.12), No_Dynamic_Accessibility_Checks, which prevents dangling reference problems at compile time.

This restriction has no effect on the user-visible behavior of a program when executed; the only effect of this restriction is to enable additional compile-time checks (described below) which ensure statically that Ada’s dynamic accessibility checks will not fail.

The feature can be activated with pragma Restrictions (No_Dynamic_Accessibility_Checks);. As a result, additional compile-time checks are performed; these checks pertain to stand-alone objects, subprogram parameters, and function results as described below.

All of the refined rules are compatible with the [use of anonymous access types in SPARK] (http://docs.adacore.com/spark2014-docs/html/lrm/declarations-and-types.html#access-types).

17.3.5.1. Stand-alone objects

Var        : access T := ...
Var_To_Cst : access constant T := ...
Cst        : constant access T := ...
Cst_To_Cst : constant access constant T := ...

In this section, we will refer to a stand-alone object of an anonymous access type as an SO.

When the restriction is in effect, the “statically deeper” relationship (see RM 3.10.2(4)) does apply to the type of a SO (contrary to RM 3.10.2(19.2)) and, for the purposes of compile-time checks, the accessibility level of the type of a SO is the accessibility level of that SO. This supports many common use-cases without the employment of Unchecked_Access while still removing the need for dynamic checks.

This statically disallows cases that would otherwise require a dynamic accessibility check, such as

type Ref is access all Integer;
Ptr : Ref;
Good : aliased Integer;

procedure Proc is
   Bad : aliased Integer;
   Stand_Alone : access Integer;
begin
   if <some condition> then
      Stand_Alone := Good'Access;
   else
      Stand_Alone := Bad'Access;
   end if;
   Ptr := Ref (Stand_Alone);
end Proc;

If a No_Dynamic_Accessibility_Checks restriction is in effect, then the otherwise-legal type conversion (the right-hand side of the assignment to Ptr) becomes a violation of the RM 4.6 rule “The accessibility level of the operand type shall not be statically deeper than that of the target type …”.

17.3.5.2. Subprogram parameters

procedure P (V : access T; X : access constant T);

In most cases (the exceptions are described below), a No_Dynamic_Accessibility_Checks restriction means that the “statically deeper” relationship does apply to the anonymous type of an access parameter specifying an access-to-object type (contrary to RM 3.10.2(19.1)) and, for purposes of compile-time “statically deeper” checks, the accessibility level of the type of such a parameter is the accessibility level of the parameter.

This change (at least as described so far) doesn’t affect the caller’s side, but on the callee’s side it means that object designated by a non-null parameter of an anonymous access type is treated as having the same accessibility level as a local object declared immediately within the called subprogram.

With the restriction in effect, the otherwise-legal type conversion in the following example becomes illegal:

type Ref is access all Integer;
Ptr : Ref;

procedure Proc (Param : access Integer) is
begin
   Ptr := Ref (Param);
end Proc;

The aforementioned exceptions have to do with return statements from functions that either return the given parameter (in the case of a function whose result type is an anonymous access type) or return the given parameter value as an access discriminant of the function result (or of some discriminated part thereof). More specifically, the “statically deeper” changes described above do not apply for purposes of checking the “shall not be statically deeper” rule for access discriminant parts of function results (RM 6.5(5.9)) or in determining the legality of an (implicit) type conversion from the anonymous access type of a parameter of a function to an anonymous access result type of that function. In order to prevent these rule relaxations from introducing the possibility of dynamic accessibility check failures, compensating compile-time checks are performed at the call site to prevent cases where including the value of an access parameter as part of a function result could make such check failures possible (specifically, the discriminant checks of RM 6.5(21) or, in the case of an anonymous access result type, the RM 4.6(48) check performed when converting to that result type). These compile-time checks are described in the next section.

From the callee’s perspective, the level of anonymous access formal parameters would be between the level of the subprogram and the level of the subprogram’s locals. This has the effect of formal parameters being treated as local to the callee except in:

  • Use as a function result

  • Use as a value for an access discriminant in result object

  • Use as an assignments between formal parameters

Note that with these more restricted rules we lose track of accessibility levels when assigned to local objects thus making (in the example below) the assignment to Node2.Link from Temp below compile-time illegal.

type Node is record
   Data : Integer;
   Link : access Node;
end record;

procedure Swap_Links (Node1, Node2 : in out Node) is
   Temp : constant access Node := Node1.Link; -- We lose the "association" to Node1
begin
   Node1.Link := Node2.Link; -- Allowed
   Node2.Link := Temp;       -- Not allowed
end;

function Identity (N : access Node) return access Node is
   Local : constant access Node := N;
begin
   if True then
      return N;              -- Allowed
   else
      return Local;          -- Not allowed
   end if;
end;

17.3.5.3. Function results

function Get (X : Rec) return access T;

If the result subtype of a function is either an anonymous access (sub)type, a class-wide (sub)type, an unconstrained subtype with an access discriminant, or a type with an unconstrained subcomponent subtype that has at least one access discriminant (this last case is only possible if the access discriminant has a default value), then we say that the function result type “might require an anonymous-access-part accessibility check”. If a function has an access parameter, or a parameter whose subtype “might require an anonymous-access-part accessibility check”, then we say that the each such parameter “might be used to pass in an anonymous-access value”. If the first of these conditions holds for the result subtype of a function and the second condition holds for at least one parameter that function, then it is possible that a call to that function could return a result that contains anonymous-access values that were passed in via the parameter.

Given a function call where the result type “might require an anonymous-access-part accessibility check” and a formal parameter of that function that “might be used to pass in an anonymous-access value”, either the type of that formal parameter is an anonymous access type or it is not. If it is, and if a No_Dynamic_Access_Checks restriction is in effect, then the accessibility level of the type of the actual parameter shall be statically known to not be deeper than that of the master of the call. If it isn’t, then the accessibility level of the actual parameter shall be statically known to not be deeper than that of the master of the call.

Function result example:

declare
   type T is record
      Comp : aliased Integer;
   end record;

   function Identity (Param : access Integer) return access Integer is
   begin
      return Param;        -- Legal
   end;

   function Identity_2 (Param : aliased Integer) return access Integer is
   begin
      return Param'Access; -- Legal
   end;

   X : access Integer;
begin
   X := Identity (X);      -- Legal
   declare
      Y : access Integer;
      Z : aliased Integer;
   begin
      X := Identity (Y);   -- Illegal since Y is too deep
      X := Identity_2 (Z); -- Illegal since Z is too deep
   end;
end;

In order to avoid having to expand the definition of “might be used to pass in an anonymous-access value” to include any parameter of a tagged type, the No_Dynamic_Access_Checks restriction also imposes a requirement that a type extension cannot include the explicit definition of an access discriminant.

Here is an example of one such case of an upward conversion which would lead to a memory leak:

declare
   type T is tagged null record;
   type T2 (Disc : access Integer) is new T with null record; -- Must be illegal

   function Identity (Param : aliased T'Class) return access Integer is
   begin
      return T2 (T'Class (Param)).Disc; -- Here P gets effectively returned and set to X
   end;

   X : access Integer;
begin
   declare
      P : aliased Integer;
      Y : T2 (P'Access);
   begin
      X := Identity (T'Class (Y)); -- Pass local variable P (via Y's discriminant),
                                 -- leading to a memory leak.
   end;
end;
```

Thus we need to make the following illegal to avoid such situations:

```ada
package Pkg1 is
   type T1 is tagged null record;
   function Func (X1 : T1) return access Integer is (null);
end;

package Pkg2 is
   type T2 (Ptr1, Ptr2 : access Integer) is new Pkg1.T1 with null record; -- Illegal
   ...
end;

In order to prevent upward conversions of anonymous function results (like below), we also would need to assure that the level of such a result (from the callee’s perspective) is statically deeper:

declare
   type Ref is access all Integer;
   Ptr : Ref;
   function Foo (Param : access Integer) return access Integer is
   begin
      return Result : access Integer := Param; do
         Ptr := Ref (Result); -- Not allowed
      end return;
   end;
begin
   declare
      Local : aliased Integer;
   begin
      Foo (Local'Access).all := 123;
   end;
end;

17.3.6. Case pattern matching

The selector for a case statement (but not for a case expression) may be of a composite type, subject to some restrictions (described below). Aggregate syntax is used for choices of such a case statement; however, in cases where a “normal” aggregate would require a discrete value, a discrete subtype may be used instead; box notation can also be used to match all values.

Consider this example:

type Rec is record
   F1, F2 : Integer;
end record;

procedure Caser_1 (X : Rec) is
begin
   case X is
      when (F1 => Positive, F2 => Positive) =>
         Do_This;
      when (F1 => Natural, F2 => <>) | (F1 => <>, F2 => Natural) =>
         Do_That;
      when others =>
          Do_The_Other_Thing;
   end case;
end Caser_1;

If Caser_1 is called and both components of X are positive, then Do_This will be called; otherwise, if either component is nonnegative then Do_That will be called; otherwise, Do_The_Other_Thing will be called.

In addition, pattern bindings are supported. This is a mechanism for binding a name to a component of a matching value for use within an alternative of a case statement. For a component association that occurs within a case choice, the expression may be followed by is <identifier>. In the special case of a “box” component association, the identifier may instead be provided within the box. Either of these indicates that the given identifier denotes (a constant view of) the matching subcomponent of the case selector.

Attention

Binding is not yet supported for arrays or subcomponents thereof.

Consider this example (which uses type Rec from the previous example):

procedure Caser_2 (X : Rec) is
begin
   case X is
      when (F1 => Positive is Abc, F2 => Positive) =>
         Do_This (Abc)
      when (F1 => Natural is N1, F2 => <N2>) |
           (F1 => <N2>, F2 => Natural is N1) =>
         Do_That (Param_1 => N1, Param_2 => N2);
      when others =>
         Do_The_Other_Thing;
   end case;
end Caser_2;

This example is the same as the previous one with respect to determining whether Do_This, Do_That, or Do_The_Other_Thing will be called. But for this version, Do_This takes a parameter and Do_That takes two parameters. If Do_This is called, the actual parameter in the call will be X.F1.

If Do_That is called, the situation is more complex because there are two choices for that alternative. If Do_That is called because the first choice matched (i.e., because X.F1 is nonnegative and either X.F1 or X.F2 is zero or negative), then the actual parameters of the call will be (in order) X.F1 and X.F2. If Do_That is called because the second choice matched (and the first one did not), then the actual parameters will be reversed.

Within the choice list for single alternative, each choice must define the same set of bindings and the component subtypes for for a given identifier must all statically match. Currently, the case of a binding for a nondiscrete component is not implemented.

If the set of values that match the choice(s) of an earlier alternative overlaps the corresponding set of a later alternative, then the first set shall be a proper subset of the second (and the later alternative will not be executed if the earlier alternative “matches”). All possible values of the composite type shall be covered. The composite type of the selector shall be an array or record type that is neither limited nor class-wide. Currently, a “when others =>” case choice is required; it is intended that this requirement will be relaxed at some point.

If a subcomponent’s subtype does not meet certain restrictions, then the only value that can be specified for that subcomponent in a case choice expression is a “box” component association (which matches all possible values for the subcomponent). This restriction applies if:

  • the component subtype is not a record, array, or discrete type; or

  • the component subtype is subject to a non-static constraint or has a predicate; or:

  • the component type is an enumeration type that is subject to an enumeration representation clause; or

  • the component type is a multidimensional array type or an array type with a nonstatic index subtype.

Support for casing on arrays (and on records that contain arrays) is currently subject to some restrictions. Non-positional array aggregates are not supported as (or within) case choices. Likewise for array type and subtype names. The current implementation exceeds compile-time capacity limits in some annoyingly common scenarios; the message generated in such cases is usually “Capacity exceeded in compiling case statement with composite selector type”.

17.3.7. Mutably Tagged Types with Size’Class Aspect

For a specific tagged nonformal type T that satisfies some conditions described later in this section, the universal-integer-valued type-related representation aspect Size'Class may be specified; any such specified aspect value shall be static.

Specifying this aspect imposes an upper bound on the sizes of all specific descendants of T (including T itself). T’Class (but not T) is then said to be a “mutably tagged” type - meaning that T’Class is a definite subtype and that the tag of a variable of type T’Class may be modified by assignment in some cases described later in this section. An inherited Size'Class aspect value may be overridden, but not with a larger value.

If the Size'Class aspect is specified for a type T, then every specific descendant of T (including T itself)

  • shall have a Size that does not exceed the specified value; and

  • shall have a (possibly inherited) Size'Class aspect that does not exceed the specifed value; and

  • shall be undiscriminated; and

  • shall have no composite subcomponent whose subtype is subject to a nonstatic constraint; and

  • shall not have a tagged partial view other than a private extension; and

  • shall not be a descendant of an interface type; and

  • shall not have a statically deeper accessibility level than that of T.

If the Size'Class aspect is not specified for a type T (either explicitly or by inheritance), then it shall not be specified for any descendant of T.

Example:

type Root_Type is tagged null record with Size'Class => 16 * 8;

type Derived_Type is new Root_Type with record
   Stuff : Some_Type;
end record;  -- ERROR if Derived_Type exceeds 16 bytes

Because any subtype of a mutably tagged type is definite, it can be used as a component subtype for enclosing array or record types, as the subtype of a default-initialized stand-alone object, or as the subtype of an uninitialized allocator, as in this example:

Obj : Root_Type'Class;
type Array_of_Roots is array (Positive range <>) of Root_Type'Class;

Default initialization of an object of such a definite subtype proceeds as for the corresponding specific type, except that Program_Error is raised if the specific type is abstract. In particular, the initial tag of the object is that of the corresponding specific type.

There is a general design principle that if a type has a tagged partial view, then the type’s Size'Class aspect (or lack thereof) should be determinable by looking only at the partial view. That provides the motivation for the rules of the next two paragraphs.

If a type has a tagged partial view, then a Size'Class aspect specification may be provided only at the point of the partial view declaration (in other words, no such aspect specification may be provided when the full view of the type is declared). All of the above rules (in particular, the rule that an overriding Size'Class aspect value shall not be larger than the overridden inherited value) are also enforced when the full view (which may have a different ancestor type than that of the partial view) is declared. If a partial view for a type inherits a Size'Class aspect value and does not override that value with an explicit aspect specification, then the (static) aspect values inherited by the partial view and by the full view shall be equal.

An actual parameter of an instantiation whose corresponding formal parameter is a formal tagged private type shall not be either mutably tagged or the corresponding specific type of a mutably tagged type.

For the legality rules in this section, the RM 12.3(11) rule about legality checking in the visible part and formal part of an instance is extended (in the same way that it is extended in many other places in the RM) to include the private part of an instance.

An object (or a view thereof) of a tagged type is defined to be “tag-constrained” if it is

  • an object whose type is not mutably tagged; or

  • a constant object; or

  • a view conversion of a tag-constrained object; or

  • a view conversion to a type that is not a descendant of the operand’s type; or

  • a formal in out or out parameter whose corresponding actual parameter is tag-constrained; or

  • a dereference of an access value.

In the case of an assignment to a tagged variable that is not tag-constrained, no check is performed that the tag of the value of the expression is the same as that of the target (RM 5.2 notwithstanding). Instead, the tag of the target object becomes that of the source object of the assignment. Note that the tag of an object of a mutably tagged type MT will always be the tag of some specific type that is a descendant of MT. An assignment to a composite object similarly copies the tags of any subcomponents of the source object that have a mutably tagged type.

The Constrained attribute is defined for any name denoting an object of a mutably tagged type (RM 3.7.2 notwithstanding). In this case, the Constrained attribute yields the value True if the object is tag-constrained and False otherwise.

Renaming is not allowed (see RM 8.5.1) for a type conversion having an operand of a mutably tagged type MT and a target type TT such that TT (or its corresponding specific type if TT is class-wide) is not an ancestor of MT (this is sometimes called a “downward” conversion), nor for any part of such an object, nor for any slice of any part of such an object. This rule also applies in any context where a name is required to be one for which “renaming is allowed” (for example, see RM 12.4). [This is analogous to the way that renaming is not allowed for a discriminant-dependent component of an unconstrained variable.]

A name denoting a view of a variable of a mutably tagged type shall not occur as an operative constituent of the prefix of a name denoting a prefixed view of a callable entity, except as the callee name in a call to the callable entity. This disallows, for example, renaming such a prefixed view, passing the prefixed view name as a generic actual parameter, or using the prefixed view name as the prefix of an attribute.

The execution of a construct is erroneous if the construct has a constituent that is a name denoting a subcomponent of a tagged object and the object’s tag is changed by this execution between evaluating the name and the last use (within this execution) of the subcomponent denoted by the name. This is analogous to the RM 3.7.2(4) rule about discriminant-dependent subcomponents.

If the type of a formal parameter is a specific tagged type, then the execution of the call is erroneous if the tag of the actual is changed while the formal parameter exists (that is, before leaving the corresponding callable construct). This is analogous to the RM 6.4.1(18) rule about discriminated parameters.

17.3.8. No_Raise aspect

The No_Raise aspect can be applied to a subprogram to declare that this subprogram is not expected to raise an exception. Should an exception still be raised during the execution of the subprogram, it is caught at the end of this execution and Program_Error is propagated to the caller.

17.3.9. Inference of Dependent Types in Generic Instantiations

If a generic formal type T2 depends on another formal type T1, the actual for T1 can be inferred from the actual for T2. That is, you can give the actual for T2, and leave out the one for T1.

For example, Ada.Unchecked_Deallocation has two generic formals:

generic
   type Object (<>) is limited private;
   type Name is access Object;
procedure Ada.Unchecked_Deallocation (X : in out Name);

where Name depends on Object. With this language extension, you can leave out the actual for Object, as in:

type Integer_Access is access all Integer;

procedure Free is new Unchecked_Deallocation (Name => Integer_Access);

The compiler will infer that the actual type for Object is Integer. Note that named notation is always required when using inference.

The following inferences are allowed:

  • For a formal access type, the designated type can be inferred.

  • For a formal array type, the index type(s) and the component type can be inferred.

  • For a formal type with discriminants, the type(s) of the discriminants can be inferred.

Example for arrays:

generic
   type Element_Type is private;
   type Index_Type is (<>);
   type Array_Type is array (Index_Type range <>) of Element_Type;
package Array_Operations is
   ...
end Array_Operations;

...

type Int_Array is array (Positive range <>) of Integer;

package Int_Array_Operations is new Array_Operations (Array_Type => Int_Array);

The index and component types of Array_Type are inferred from Int_Array, so that the above instantiation is equivalent to the following standard-Ada instantiation:

package Int_Array_Operations is new Array_Operations
   (Element_Type => Integer,
      Index_Type   => Positive,
      Array_Type   => Int_Array);

17.3.10. External_Initialization Aspect

The External_Initialization aspect provides a feature similar to Rust’s include_bytes! and to C23’s #embed. It has the effect of initializing an object with the contents of a file specified by a file path.

Only string objects and objects of type Ada.Streams.Stream_Element_Array can be subject to the External_Initialization aspect.

Example:

with Ada.Streams;

package P is
   S : constant String with External_Initialization => "foo.txt";

   X : constant Ada.Streams.Stream_Element_Array with External_Initialization => "bar.bin";
end P;

External_Initialization aspect accepts the following parameters:

  • mandatory Path: the path the compiler uses to access the binary resource.

If Path is a relative path, it is interpreted relatively to the directory of the file that contains the aspect specification.

Attention

The maximum size of loaded files is limited to 231 bytes.

17.3.11. Finally construct

The finally keyword makes it possible to have a sequence of statements be executed when another sequence of statements is completed, whether normally or abnormally.

This feature is similar to the one with the same name in other languages such as Java.

17.3.11.1. Syntax

handled_sequence_of_statements ::=
     sequence_of_statements
  [exception
     exception_handler
    {exception_handler}]
  [finally
    sequence_of_statements]

17.3.11.2. Legality Rules

Return statements in the sequence_of_statements attached to the finally that would cause control to be transferred outside the finally part are forbidden.

Goto & exit where the target is outside of the finally’s sequence_of_statements are forbidden

17.3.11.3. Dynamic Semantics

Statements in the optional sequence_of_statements contained in the finally branch will be executed unconditionally, after the main sequence_of_statements is executed, and after any potential exception_handler is executed.

If an exception is raised in the finally part, it cannot be caught by the exception_handler.

Abort/ATC (asynchronous transfer of control) cannot interrupt a finally block, nor prevent its execution, that is the finally block must be executed in full even if the containing task is aborted, or if the control is transferred out of the block.

17.3.12. Continue statement

The continue keyword makes it possible to stop execution of a loop iteration and continue with the next one. A continue statement has the same syntax (except “exit” is replaced with “continue”), static semantics, and legality rules as an exit statement. The difference is in the dynamic semantics: where an exit statement would cause a transfer of control that completes the (implicitly or explicitly) specified loop_statement, a continue statement would instead cause a transfer of control that completes only the current iteration of that loop_statement, like a goto statement targeting a label following the last statement in the sequence of statements of the specified loop_statement.

Note that continue is a keyword but it is not a reserved word. This is a configuration that does not exist in standard Ada.

17.3.13. Destructors

The Destructor aspect can be applied to any record type, tagged or not. It must denote a primitive of the type that is a procedure with one parameter of the type and of mode in out:

type T is record
   ...
end record with Destructor => Foo;

procedure Foo (X : in out T);

This is equivalent to the following code that uses Finalizable:

type T is record
   ...
end record with Finalizable => (Finalize => Foo);

procedure Foo (X : in out T);

Unlike Finalizable, however, Destructor can be specified on a derived type. And when it is, the effect of the aspect combines with the destructors of the parent type. Take, for example:

type T1 is record
   ...
end record with Destructor => Foo;

procedure Foo (X : in out T1);

type T2 is new T1 with Destructor => Bar;

procedure Bar (X : in out T2);

Here, when an object of type T2 is finalized, a call to Bar will be performed and it will be followed by a call to Foo.

The Destructor aspect comes with a legality rule: if a primitive procedure of a type is denoted by a Destructor aspect specification, it is illegal to override this procedure in a derived type. For example, the following is illegal:

type T1 is record
   ...
end record with Destructor => Foo;

procedure Foo (X : in out T1);

type T2 is new T1;

overriding
procedure Foo (X : in out T2); -- Error here

It is possible to specify Destructor on the completion of a private type, but there is one more restriction in that case: the denoted primitive must be private to the enclosing package. This is necessary due to the previously mentioned legality rule, to prevent breaking the privacy of the type when imposing that rule on outside types that derive from the private view of the type.