!standard 3.9.3(6/2) 13-10-24 AI05-0080-1/01 !class presentation 13-10-21 !status work item 13-10-21 !status received 13-06-16 !priority Low !difficulty Easy !qualifier Omission !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) None yet. !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.) !recommendation (See Summary.) !wording 1) Modify 3.9.3(6): 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. 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. !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). !corrigendum 3.9.3(6) @drepl @xbullet. 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.> @dby @xbullet. 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.> !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 ... ****************************************************************