Re: Optional body for nested generic

[Adam Beneschan <adam@irvine.com>]

On Sep 20, 5:48 am, Simon Wright <si...@pushface.org> wrote:
> I was surprised to find that GNAT makes it optional to have a body for a
                               ^^^^

I believe you misspelled "Ada".

> nested generic package (in the code below, gpack1 has an empty body,
> gpack2 doesn't have a body at all).
>
> package Pack is
>    pragma Elaborate_Body;
>    generic
>    package Gpack1 is
>       procedure Proc;
>       pragma Import (C, Proc, "proc");
>    end Gpack1;
>    generic
>    package Gpack2 is
>       procedure Proc;
>       pragma Import (C, Proc, "proc");
>    end Gpack2;
> end Pack;
>
> package body Pack is
>    package body Gpack1 is
>    end Gpack1;
> end Pack;
>
> I suppose that the reasoning for disallowing unrequired bodies (roughly,
> making it impossible to obsolete the ada library by adding/removing
> something with no other impact) only applies at library level, where
> there's a correspondence to a file?

The rule indeed applies only to library packages (including generic
packages); it's in RM 7.2(4).  Since it's a language rule and not a
GNAT rule, it doesn't have anything to do wtih "correspondence to a
file"; however, since any compiler *allows* library package specs and
bodies to be processed in different runs of the compiler (even if it
doesn't require this), allowing a package body that isn't needed can
lead to confusion (if, say, a package spec is changed from one that
requires a body to one that doesn't---what happens to the body that
was previously compiled?).  See the Ada 95 Rationale, 10.4: "In Ada
83, if a package does not require a body, but has one nevertheless
(perhaps to do some initialization), its body can become out-of-date,
and be silently omitted form a subsequent build of an executable
program.  This can lead to mysterious run-time failures...".  This
reasoning doesn't apply in non-library package cases.

                         -- Adam