!standard 3.1(6/2) 11-11-12 AI05-0277-1/01 !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 Modify 3.1(6/3): 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: 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). !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! ****************************************************************