[EDIT: Now I see that the author of issue #177 has essentially suggested this same thing, quote:
(library-level finalization could be handled in a
new "final" part, which would be the counterpart to elaboration ...
Thus, no credit to me for the idea, and apologies for missing that, and possibly adding noise. Still, since this proposal may be useful even if issue #177 is not accepted (as even its author seems to suggest), I leave this issue on the table.]
In issue #177, discussing explicit finalization calls, the following is stated:
The other exception would be libary-level finalization. There is nowhere
to put those calls, they need to exist in the code that occurs after the
main subprogram returns (and after task waiting). In a new language, one
could make all of that explicit, too, but it seems impossible to do so in
Ada without massive incompatibility.
Here I propose a syntax for package finalization, including for library-level packages at program termination. Whether it can be implemented reasonably needs discussion, but to me it does not seem to be harder than the current implementation of library-level elaboration.
The idea is to have an optional terminate block in any package body, after the optional elaboration begin block. For example:
package body P is
... Some declarations.
begin
... Some initialization statements.
terminate
... Some statements to finalize the package.
end P;
For a library-level package, the statements in the terminate block are executed after the main subprogram returns and the awaited tasks have terminated. This library-level finalization process seems quite symmetric with the library-level elaboration process. The order in which packages must be finalized is the reverse of their elaboration order -- that is, if the finalization code of package P depends on services from package Q, P must be finalized before Q. There could be a "finalization check", analogous to the elaboration check, but for finalization any required checks could instead be implemented by the programmer, rather than being a compiler's responsibility.
I don't see why this addition to Ada would cause "massive incompatibility" with existing Ada programs, which of course do not contain such optional terminate blocks.
If the explicit finalization in issue #177 is adopted, such terminate blocks offer a place for the required finalization calls, but terminate blocks could be useful even if #177 is not adopted.
[EDIT: Now I see that the author of issue #177 has essentially suggested this same thing, quote:
Thus, no credit to me for the idea, and apologies for missing that, and possibly adding noise. Still, since this proposal may be useful even if issue #177 is not accepted (as even its author seems to suggest), I leave this issue on the table.]
In issue #177, discussing explicit finalization calls, the following is stated:
Here I propose a syntax for package finalization, including for library-level packages at program termination. Whether it can be implemented reasonably needs discussion, but to me it does not seem to be harder than the current implementation of library-level elaboration.
The idea is to have an optional terminate block in any package body, after the optional elaboration begin block. For example:
For a library-level package, the statements in the terminate block are executed after the main subprogram returns and the awaited tasks have terminated. This library-level finalization process seems quite symmetric with the library-level elaboration process. The order in which packages must be finalized is the reverse of their elaboration order -- that is, if the finalization code of package
Pdepends on services from packageQ,Pmust be finalized beforeQ. There could be a "finalization check", analogous to the elaboration check, but for finalization any required checks could instead be implemented by the programmer, rather than being a compiler's responsibility.I don't see why this addition to Ada would cause "massive incompatibility" with existing Ada programs, which of course do not contain such optional terminate blocks.
If the explicit finalization in issue #177 is adopted, such terminate blocks offer a place for the required finalization calls, but terminate blocks could be useful even if #177 is not adopted.