Version 1.1 of acs/ac-00213.txt

Unformatted version of acs/ac-00213.txt version 1.1
Other versions for file acs/ac-00213.txt

!standard 8.3.1(3-4)          11-01-28 AC95-00213/01
!standard 9.4(11.10)
!standard 9.4(11.11)
!standard 9.5.2(5)
!class confirmation 11-01-28
!status received no action 11-01-28
!status received 10-11-29
!subject Overriding indicators on protected subprogram/entry bodies
!summary
!appendix

!topic Overriding indicators on protected subprogram/entry bodies
!reference 8.3.1(3-4), 9.5.2(5), 9.4(11.10-11.12)
!from Adam Beneschan 10-11-29
!discussion

In this example:

    protected type My_Protected is new P.My_Interface with
       overriding              -- (1)
       procedure Do_Something;
    end My_Protected;

    protected body My_Protected is
       overriding              -- (2)
       procedure Do_Something is
       begin
          null;
       end Operation;
    end My_Protected;

What are the intended rules about "overriding" on protected subprogram
bodies?

8.3.1(3) has rules about when an overriding_indicator may appear on a
subprogram_body, or on a subprogram_declaration other than a protected
subprogram.  The punctuation makes it appear that the clause "other
than a protected subprogram" applies only to the
"subprogram_declaration".  Thus, while the line (1) is not covered by
this rule, line (2) is.  (Note also that 9.4(11.10-11.12) deal with
overriding indicators on protected subprogram *declarations*, but in
that section seems to deal with them on protected subprogram bodies.)
However, since a subprogram declared in a protected type declaration
can never be a primitive operation (8.3.1(4)), this would seem to mean
that overriding_indicators can never be applied to protected
subprogram bodies.

Furthermore, while overriding_indicators can be applied to protected
entry declarations, the syntax of an entry_body doesn't allow for
overriding_indicators at all (9.5.2(5)).

Is this the intent?  For non-protected subprograms, you're allowed to
put the same overriding indicator on the declaration and body.  Should
this be allowed on protected subprogram bodies and protected entry
bodies, for consistency?  Apparently some versions of GNAT compile
this, based on a comp.lang.ada post on 10/27/2010 by Maciej Sobczak,
although version 4.3.3 does not.

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

From: Randy Brukardt
Sent: Monday, November 29, 2010  1:45 PM

> !topic Overriding indicators on protected subprogram/entry bodies

An off-the-cuff answer...

...
> What are the intended rules about "overriding" on protected subprogram
> bodies?

They're not allowed, I think.

...
> Is this the intent?

Yes, I think it is.

> For non-protected subprograms, you're allowed to put the same
> overriding indicator on the declaration and body.

You *can* do this, in *some* circumstances, but it doesn't work in general.
(The body and the specification may have different visibility, leading to
different indicators.)

The intent is that the indicators are *not* repeated on the bodies.
Subprogram bodies are allowed to have indicators for two reasons: because they
can act as declarations; and because there are cases where you can't give an
indicator on the specification due to visibility (you may not be able to put
"overriding" on the specification). Neither reason applies to protected
subprogram bodies.

> Should this be allowed on protected
> subprogram bodies and protected entry bodies, for consistency?

No, doing so is "wrong" (not the intended way to use the language).

Also note that it really doesn't make sense to put an indicator on a protected
body, as it doesn't override anything. Indeed, it is odd to be able to put
indicators on subprogram bodies that don't override anything - if there is a
mistake in the language, that is it.

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

From: Adam Beneschan
Sent: Monday, November 29, 2010  4:07 PM

OK, thanks for the explanation.  I wonder how much programmers are aware that
this isn't the intent.  It appears that there's at least one publicly available
Ada suite in which the programmer routinely repeats the overriding indicators
from the package spec to the body, but I don't know how widespread this
(apparently wrong) practice is.

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

From: Stephen Leake
Sent: Monday, November 29, 2010  4:18 PM

The GNAT style check:

gnatmake -gnatyO

forces 'overriding' on subprogram bodies.

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

Private musings from Randy Brukardt (January 28, 2011)

Note that this is similar to the disallowance of indicators on non-primitive
subprograms.

My position was that indicators should be allowed everywhere (specifically
"not overriding"). Of course, "overriding" should only be allowed where that
actually is happening. That was because "primitiveness" isn't something that
is easily determined by a reader (it's easier for a compiler, but us humans
aren't compilers).

However, I lost that argument throughly. I don't think *anyone* else supported
that position.

So it is consistent for primitive subprograms to work that way as well. A
protected body isn't overriding anything, and it isn't primitive. There
are some special rules for protected subprogram specifications that are
"implementing" something, but a body can never do that.

Indicators are syntactically allowed because no one thought it was worth
it to change the syntax of protected bodies in some way to disallow them.
The existence of syntax doesn't mean that they are legal!

If we were to change this, we clearly would need to allow indicators for
entry_bodies as well (and accept statements??). It would be odd for them to
be different.

I don't think we should make any change. Note that I have this opinion now
because I argued strongly in favor of expansive semantics for them originally
(allow them everywhere, allow "not overriding" everywhere other than where
"overriding" is allowed). I lost that argument. I don't see any good reason to
now do a partial or complete flip-flop on that -- it just isn't important
enough, and what has changed?

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

Questions? Ask the ACAA Technical Agent