!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? ***************************************************************