Version 1.4 of ai12s/ai12-0080-1.txt

Unformatted version of ai12s/ai12-0080-1.txt version 1.4
Other versions for file ai12s/ai12-0080-1.txt

!standard 3.9.3(6/2)          13-12-11 AI05-0080-1/02
!standard B.1(50)
!class presentation 13-10-21
!status Corrigendum 2014 13-12-11
!status work item 13-10-21
!status received 13-06-16
!priority Low
!difficulty Easy
!qualifier Clarification
!subject More presentation errors in Ada 2012
!summary
[Editor's note: These changes are included in the draft Standard immediately, as they are considered non-normative and non-controversal. However, they are not yet approved, and thus have more risk of change.]
This AI corrects minor errors in the Standard.
1) An abstract function inherited for a null extension still requires overriding.
2) The examples in B.1 are of interfacing aspects, of course.
!question
1) The following appears to be legal:
package Pack1 is type T1 is abstract tagged record ... end record; function Create (N : Integer) return T1 is abstract; end Pack1;
package Pack2 is type T2 is new Pak1.T1 with private; private type T2 is new Pak1.T1 with null record; end Pack2;
as Create is "a function with a controlling result" inherited by a private extension, as described in 3.9.3(6). But Create is abstract, and we don't want abstract subprograms of nonabstract tagged types. Should this be fixed? (Yes.)
2) B.1(50) says that the examples are of "interfacing pragmas", but all of the following examples are of "interfacing aspects". Should this be fixed? (Yes.)
!recommendation
(See Summary.)
!wording
1) Modify 3.9.3(6/2):
Otherwise, the subprogram shall be overridden with a nonabstract subprogram or, in the case of a private extension inheriting a {nonabstract} function with a controlling result, have a full type that is a null extension; for a type declared in the visible part of a package, the overriding may be either in the visible or the private part. Such a subprogram is said to @i<require overriding>. However, if the type is a generic formal type, the subprogram need not be overridden for the formal type itself; a nonabstract version will necessarily be provided by the actual type.
2) Modify B.1(50):
Example of interfacing {aspects}[pragmas]:
!discussion
1) This problem was noted in the e-mail appendix to AI95-00391-1 (which originally defined this wording), but for some reason the fix was never applied. It obviously would make no sense to allow an abstract routine to be inherited but not be overridden for a nonabstract type (of any kind).
2) Since the clause title is "Interfacing aspects", it's pretty clear what the intent is!
!corrigendum 3.9.3(6/2)
Replace the paragraph:
by:
!corrigendum B.1(50)
Replace the paragraph:
Examples of interfacing pragmas:
by:
Examples of interfacing aspects:
!ASIS
No changes needed.
!ACATS test
No test needed.
!appendix

!topic Missing word in 3.9.3(6)?
!reference 3.9.3(6)
!from Adam Beneschan 13-08-08
!discussion

3.9.3(6) says:

    Otherwise, the subprogram shall be overridden with a nonabstract
    subprogram or, in the case of a private extension inheriting a
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    function with a controlling result, have a full type that is a
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        
    null extension; for a type declared in the visible part of a
    package, the overriding may be either in the visible or the
    private part. Such a subprogram is said to require
    overriding. However, if the type is a generic formal type, the
    subprogram need not be overridden for the formal type itself; a
    nonabstract version will necessarily be provided by the actual
    type.

Shouldn't the clause I marked say

    or, in the case of a private extension inheriting a
    **nonabstract** function with a controlling result, ...

?  The intent is obviously that private extensions whose full type is
a null extension don't have to override functions with controlling
results.  But a function with a controlling result could also be
abstract, and we don't want the rule to apply in that case.  Otherwise
I think this would be legal:

    package Pack1 is
        type T1 is abstract tagged record ... end record;
        function Create (N : Integer) return T1 is abstract;
    end Pack1;

    package Pack2 is
        type T2 is new Pak1.T1 with private;
    private
        type T2 is new Pak1.T1 with null record;
    end Pack2;

It's really a bit of a nitpick since the intent is obvious, but I
think it should be corrected.

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

From: Adam Beneschan
Sent: Thursday, August 8, 2013  8:01 PM

Heh... I just noticed (9 years after the fact) that Tucker mentioned this
at the end of AI95-391, but apparently it didn't get in ...

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

From: Randy Brukardt
Sent: Friday, September 27, 2013  7:51 PM

B.1(50) says "examples of interfacing PRAGMAS", but the examples are all of
aspects. Grump.

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

Questions? Ask the ACAA Technical Agent