!standard 5.6.1(2/5)                                  21-05-29  AI12-0436-1/01
!class Amendment 21-05-29
!status Amendment 1-2012 21-06-04
!status WG9 Approved 22-06-22
!status ARG Approved 8-1-5  21-06-03
!status work item 21-05-29
!status received 21-05-29
!priority Low
!difficulty Easy
!subject Should parallel blocks include exception handlers?
!summary

Parallel blocks should consist of a set of sequence_of_statements.

!problem

A parallel block currently consists of a set of handled_sequence_of_statements.
In all existing uses of handled_sequence_of_statement, it is immediately
followed by the reserved word "end". The exception handler is traditionally
aligned with "end".

Additionally, the syntax as written requires the exception handler to be
indented one level, and the regular statements of each limb to be indented
two levels. This would be a very unusual way to write an Ada construct.
Here's how the first example of 5.6.1 would look with the suggested
indentation:

      parallel do
            Traverse (T.Left);
         exception
            when others => null;
      and
            Traverse (T.Right);
         exception
            when others => null;
      and
            Ada.Text_IO.Put_Line
               ("Processing " & Ada.Tags.Expanded_Name (T'Tag));
         exception
            when others => null;
      end do;

This is a highly unusual format for Ada; there is nothing like it elsewhere.

Following normal practice and putting the exception handlers at the level
of the "do" and "end" results in an unreadable mess:

      parallel do
         Traverse (T.Left);
      exception
         when others => null;
      and
         Traverse (T.Right);
      exception
         when others => null;
      and
         Ada.Text_IO.Put_Line
            ("Processing " & Ada.Tags.Expanded_Name (T'Tag));
      exception
         when others => null;
      end do;

It is difficult to see what is executing in parallel here, and it would be
worse if the handlers actually contained logging or retrying code.

!proposal

(See Summary.)

!wording

Replace "handled_sequence_of_statements" with "sequence_of_statements" in
5.6.1(2/5) (as well as 5.6.1(1/5) and 5.6.1(3/5)).

!discussion

It was pointed out that many other uses of handled_sequence_of_statements show
it as double indented (both regular blocks and accept_statements make this 
mistake). This appears to be mainly a mistake in the way the RM is defined,
as both practice and RM examples show the handler aligned with the "end" for
blocks and accept_statements.

Note that "handled_sequence_of_statements" is at best a convenience, as one
can always include a block to include a handler. Indeed, that is such common
practice in Ada that many users will do so even when they don't have to
(blocks with handlers are commonly seen in accept_statements, for instance).
And if declarations are needed, a block has to be used in any case.

Additionally, if someone is willing to indent the handlers an extra level
to make the result more readable, using a block looks essentially the same.
For instance, for the example above:

      parallel do
         begin
            Traverse (T.Left);
         exception
            when others => null;
         end;
      and
         begin
            Traverse (T.Right);
         exception
            when others => null;
         end;
      and
         begin
            Ada.Text_IO.Put_Line
               ("Processing " & Ada.Tags.Expanded_Name (T'Tag));
         exception
            when others => null;
         end;
      end do;

If we allow handled_sequence_of_statements now, that cannot ever be undone
without incurring significant incompatibility. OTOH, if we go with 
sequence_of_statements, that could be compatibly changed to
handled_sequence_of_statements in the future (if practice indeed showed that
bare handlers are common in this situation, and someone comes up with
readable way to write these things).

!corrigendum 5.6.1(0)

@dinsc
See the conflict file for the changes.

!ASIS

No ASIS effect.

!ACATS test

No ACATS tests needed.

!appendix

****************************************************************