!standard 3.9.3(8/3) 10-02-13 AI05-0203-1/01 !class binding interpretation 10-02-13 !status work item 10-02-13 !status received 09-09-24 !priority Low !difficulty Easy !qualifier Omission !subject A return_subtype_indication cannot denote an abstract subtype !summary A return_subtype_indication cannot denote an abstract subtype. !question There does not seems to be a rule that makes this illegal, although surely it must be: function Func return Abstract_Type'Class is begin return X : Abstract_Type; end Func; Nothing in 3.9.3(8) applies to this (since it's not an object_declaration). !recommendation (See Summary.) !wording Add after the fourth sentence of 3.9.3(8/3): The type denoted by a return_subtype_indication shall not be abstract. !discussion In the example in the question, the function is legal because it is returning a class-wide type, which is never abstract (3.9.3(1.2/2)). Since any type that is covered by the class-wide type is allowed in the extended_return_statement, we could declare a specific abstract type as shown. So we need to explcitly disallow this case. --!corrigendum 3.9.3(8/3) !ACATS Test An ACATS B-Test should be created that checks this rule. !appendix !topic Extended return with abstract type?? !reference 3.9.3(8), 6.5 !from Adam Beneschan 09-11-24 !discussion One more for the "abstract screwups" AI (AI05-73), maybe: I can't find anything in 3.9.3(8) or 6.5 that makes this illegal, although surely it must be: function Func return Abstract_Type'Class is begin return X : Abstract_Type; end Func; Nothing in 3.9.3(8) applies to this (since it's not an object_declaration). **************************************************************** From: Edmond Schonberg Sent: Tuesday, November 24, 2009 2:01 PM Well, there is 3.1 (6/2) ... " In addition, an extended_return_statement is a declaration of its defining identifier" but this is rather oblique, and does not correspond explicitly to the categories described in 3.9.3 (8). ****************************************************************