!standard 3.1(6/2) 12-11-07 AI05-0277-1/02 !standard 3.10(9/2) !standard 6.5(2.1/2) !standard 6.5(5.6/2) !standard 8.3(17) !reference AI05-0053-1 !reference AI05-0205-1 !class binding interpretation 11-11-12 !status Amendment 2012 11-11-12 !status ARG Approved 8-0-1 11-11-12 !status work item 11-11-12 !status received 11-06-20 !priority Low !difficulty Medium !qualifier Error !subject Aliased views of extended return objects !summary "Aliased" is allowed in the declaration of an extended return object if and only if the type of the object is immutably limited. !question AI05-0053-1 removes the keyword "aliased" from extended return statements. We have quite a number of code samples that use this keyword. In most of these samples, the keyword is used on an object of an immutably limited type, which is implicitly aliased by AI05-0053-1. This incompatibility could be reduced if the keyword was allowed when the type is immutably limited. Should this be allowed? (Yes.) !recommendation (See summary.) !wording Replace 3.1(6/3) with: Each of the following is defined to be a declaration: any basic_declaration; an enumeration_literal_specification; a discriminant_specification; a component_declaration; a loop_parameter_specification; an iterator_specification; a parameter_specification; a subprogram_body; an extended_return_object_declaration; an entry_declaration; an entry_index_specification; a choice_parameter_specification; a generic_formal_parameter_declaration. Modify 3.10(9/3): A view of an object is defined to be *aliased* if it is defined by an object_declaration, parameter_specification, [or] component_definition{, or extended_return_object_declaration} with the reserved word *aliased*, or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see 4.6) of an aliased view. The current instance of an immutably limited type (see 7.5) is defined to be aliased[, as is the return object of an extended_return_statement (see 6.5) that is of an immutably limited type]. Finally, a formal parameter or generic formal object of a tagged type is defined to be aliased. Aliased views are the ones that can be designated by an access value. Replace 6.5(2.1/3) with: extended_return_statement ::= return extended_return_object_declaration [do handled_sequence_of_statements end return]; Add after 6.5(5.8/3): If the keyword aliased is present in an extended_return_object_declaration, the type of the extended return object shall be immutably limited. Remove the change added after 8.3(17) by AI05-0205-1. !discussion This reverses part of the decisions of AI05-0053-1. We still require that the object be immutably limited in order for it to be aliased (so that it is required to be built-in-place), but we now explicitly require the keyword. In addition, we change the syntax to make it easier to talk about the declaration of an extended return object. Having done so, we can effectively handle AI05-0205-1 with the change that was described in that AI as "too hard". Thus we change 3.1(6/3) and then eliminate the change in 8.3(17). The new rule is still somewhat incompatible with Ada 2005, in that the keyword can no longer be given on objects of types that are not immutably limited. However, due to an oversight in the Standard, extended return objects are never aliased in Ada 2005 (even if the keyword aliased is given), so these incompatibilities should be very rare in practice. [Also recall the semantic problems outlined in AI05-0053-1; one hopes implementations did not allow these to be aliased!] !corrigendum 3.1(6/2) @drepl Each of the following is defined to be a declaration: any @fa; an @fa; a @fa; a @fa; a @fa; a @fa; a @fa; an @fa; an @fa; a @fa; a @fa. In addition, an @fa is a declaration of its @fa. @dby Each of the following is defined to be a declaration: any @fa; an @fa; a @fa; a @fa; a @fa; an @fa; a @fa; a @fa; an @fa; an @fa; an @fa; a @fa; a @fa. !corrigendum 3.10(9/2) @drepl A view of an object is defined to be @i if it is defined by an @fa or @fa with the reserved word @b, or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see 4.6) of an aliased view. The current instance of a limited tagged type, a protected type, a task type, or a type that has the reserved word @b in its full definition is also defined to be aliased. Finally, a formal parameter or generic formal object of a tagged type is defined to be aliased. Aliased views are the ones that can be designated by an access value. @dby A view of an object is defined to be @i if it is defined by an @fa, @fa, @fa, or @fa with the reserved word @b, or by a renaming of an aliased view. In addition, the dereference of an access-to-object value denotes an aliased view, as does a view conversion (see 4.6) of an aliased view. The current instance of an immutably limited type (see 7.5) is defined to be aliased. Finally, a formal parameter or generic formal object of a tagged type is defined to be aliased. Aliased views are the ones that can be designated by an access value. !corrigendum 6.5(2.1/2) @drepl @xcode<@fa@ft<@b>@fa< defining_identifier : [>@ft<@b>@fa<] return_subtype_indication [:= expression] [>@ft<@b>@fa< handled_sequence_of_statements >@ft<@b>@fa<];>> @dby @xcode<@fa@ft<@b>@fa<][>@ft<@b>@fa<] return_subtype_indication [:= expression]>> @xcode<@fa@ft<@b>@fa< extended_return_object_declaration [>@ft<@b>@fa< handled_sequence_of_statements >@ft<@b>@fa<];>> !corrigendum 6.5(5.6/2) @dinsa @xbullet of the return statement shall not be statically deeper than that of the master that elaborated the function body. If the result subtype has one or more unconstrained access discriminants, the accessibility level of the anonymous access type of each access discriminant, as determined by the @fa of the @fa or the @fa, shall not be statically deeper than that of the master that elaborated the function body.> @dinst If the keyword @b is present in an @fa, the type of the extended return object shall be immutably limited. !comment !corrigendum 8.3(17) -- removed from AI05-0205-1. !ACATS Test An ACATS C-Test should be created (but this is likely to be low priority). !ASIS ** TBD: may need changes to reflect the syntax change. However, it might be possible to ignore extended_return_object_declaration for ASIS purposes, in which case the existing queries should be enough. !appendix From: Edmond Schonberg Sent: Monday, June 20, 2011 1:45 PM This AI does two things: it modifies the syntax of extended return statements, and uses "immutably limited" to extend the notion of aliased view. In the course of implementing this innocent-looking AI we found that the syntactic change is not all that invisible: more than a dozen programs in our test suite use the keyword in extended return statements. In most cases the usage is confirming: the returned value is in fact immutably limited. Given that syntactic incompatibilities are always a red flag for users making a transition to the new language, and given that many (more than we expected) have picked up the idiom (no doubt from examples in the earlier AI, and with some intuitive understanding that these things are built in place) I wonder whether it would be appropriate to allow the keyword when it is confirming. Not the highest priority issue, but, the fewer entries in the "Incompatibilities with Ada2005" list, the better! **************************************************************** From: Bob Duff Sent: Saturday, November 12, 2011 6:20 PM I agree, except I think it IS pretty high priority. This incompatibility is completely unnecessary. **************************************************************** From: Robert Dewar Sent: Saturday, November 12, 2011 6:32 PM I agree with Bob on both points. Incompatibilities are a real problem. They have the significant effect of seriously impeding adoption. If people compile their existing code and get a bunch of mysterious errors they do not understand, then they just put off making the transition. **************************************************************** From: Tucker Taft Sent: Saturday, November 12, 2011 6:36 PM We just voted to go back to *requiring* "aliased" if you want to use 'Access, but adding a legality rule that you can only use "aliased" on an extended return object declaration if the type of the object is immutably limited. **************************************************************** From: Bob Duff Sent: Saturday, November 12, 2011 7:00 PM Good. **************************************************************** From: Randy Brukardt Sent: Friday, December 30, 2011 1:10 AM I need to point out that this is still (technically) incompatible, and thus does nothing to reduce the number of entries in the "Incompatibilities with Ada 2005" list. (And it wouldn't anyway, because there is a second incompatible item in that subclause, and there is only one index entry per subclause.) Specifically, if an Ada 2005 user had written "aliased" on an object that is not immutably limited, it is now illegal. This is a "good" incompatibility, as we don't really know how that could be implemented sanely. (It could allow an object that is built-in-place but is not declared aliased to have its 'Access taken, which is trouble as the object might not have the representation of an aliased object. There are more fun examples in the original AI - AI05-0053-1.) It's also true that "aliased" on extended return objects was formally a no-op in Ada 2005, as there was no wording making such an object aliased -- so a "correct" compiler would never have allowed anything useful anyway. (However, I suspect most Ada 2005 implementations followed the Dewar rule here, thus we have to worry about the incompatibility.) No big deal, but I didn't want any misconceptions out there. **************************************************************** From: Edmond Schonberg Sent: Friday, December 30, 2011 9:52 AM My comment was not intended to shorten the list of incompatibilities in the RM, but just to minimize the aggravation of users in the face of this change. Most of the examples I have seen apply the qualifier to immutably limited objects, so there will be fewer unwelcome surprises. A very pragmatic consideration, which unfortunately does not simplify in any way the job of the editor.... ****************************************************************