!standard 8.5.1(1) 20-07-08 AI12-0383-1/03 !standard 8.5.1(4) !standard 8.5.1(4.1/2) !standard 8.5.1(6/2) !standard 8.5.1(8) !class Amendment 20-06-10 !status Amendment 1-2012 20-06-16 !status WG9 Approved 22-06-22 !status ARG Approved 12-0-1 20-06-13 !status work item 20-06-10 !status received 20-03-26 !priority Low !difficulty Easy !subject Renaming values !summary Allow names that denote values rather than objects to nevertheless be renamed using an object renaming. !problem AI12-0068-1 specified that the current instance of a subtype visible in a predicate should be treated as a "value" rather than as an "object". That prevents use of things like 'Address and 'Size which just cause trouble. However, it highlights the fact that you can't rename a value, which is a bit annoying in some cases, particularly if the current instance is of a composite type. !proposal It would seem easy enough to permit renaming of values in an "object renaming". Especially now that we don't require you to specify the type of the thing being renamed, it seems particularly natural to allow essentially any kind of value to be renamed, including named numbers, for example. We already allow renaming of the result of functions, which most folks think of as a "value" anyway, so it is a bit confusing to then find that other things that just happen to be a value cannot be renamed. !wording Modify 8.5.1(1): [Redundant: An object_renaming_declaration is used to rename an object {or a value}.] Modify 8.5.1(4-4.1/2): The renamed entity shall be an object {or a value}. In the case where the type is defined by an access_definition, the type of the renamed [object] {entity} and the type defined by the access_definition: Modify 8.5.1 (6/2): An object_renaming_declaration declares a new view [Redundant: of the renamed [object]{entity}] whose properties are identical to those of the renamed view. [Redundant: Thus, the properties of the renamed [object]{entity} are not affected by the renaming_declaration. In particular, {its nominal subtype, whether it is a value or an object,} its value {if it is an object,} and whether or not it is a constant{,} are unaffected; similarly, the [null exclusion or] constraints {and other properties of its nominal subtype} [that apply to an object] are not affected by renaming (any constraint implied by the subtype_mark or access_definition of the object_renaming_declaration is ignored).] Add an example, after 8.5.1(8): Example of renaming a value: Uno renames One; -- see 3.3.2 !discussion Now that we have object renamings that don't require a type, and are seen more clearly as a uniform way to establish a shorthand in a local context, it doesn't make as much sense to treat named numbers or other values differently from declared constant objects. Therefore, we propose to allow the renamed entity to be a value rather than an object in an object renaming declaration. By relaxing this rule, we allow the current instance of a subtype, or any of its subcomponents, to appear in a renaming within a declare expression defining a predicate aspect. One question was whether this broke the equivalence between generic formal in-out objects and renamings, but since values are never variables, and a generic in-out requires a variable as the actual object, the equivalence principle is unaffected. Note that generic formal "in" objects are treated as newly declared constants, and in that case the actual is already allowed to be a value. !corrigendum 8.5.1(1) @drepl An @fa is used to rename an object. @dby An @fa is used to rename an object or value. !corrigendum 8.5.1(4) @drepl The renamed entity shall be an object. @dby The renamed entity shall be an object or value. !corrigendum 8.5.1(4.1/2) @drepl In the case where the type is defined by an @fa, the type of the renamed object and the type defined by the @fa: @dby In the case where the type is defined by an @fa, the type of the renamed entity and the type defined by the @fa: !corrigendum 8.5.1(6/2) @drepl An @fa declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the @fa. In particular, its value and whether or not it is a constant are unaffected; similarly, the null exclusion or constraints that apply to an object are not affected by renaming (any constraint implied by the @fa or @fa of the @fa is ignored). @dby An @fa declares a new view of the renamed entity whose properties are identical to those of the renamed view. Thus, the properties of the renamed entity are not affected by the @fa. In particular, its nominal subtype, whether it is a value or an object, its value if it is an object, and whether or not it is a constant, are unaffected; similarly, the constraints and other properties of its nominal subtype are not affected by renaming (any constraint implied by the @fa or @fa of the @fa is ignored). !corrigendum 8.5.1(8) @dinsa @xcode<@b L : Person @b Leftmost_Person; --@ft<@i< see 3.10.1>> @b L.Age := L.Age + 1; @b;> @dinss @i @xcode One; --@ft<@i< see 3.3.2>>> !example (see Wording.) !ASIS No ASIS effect. !ACATS test An ACATS C-Test is needed to check that that values can be renamed. !appendix From: Tucker Taft Sent: Monday, April 27, 2020 6:27 AM AI12-0068-1 specified that the current instance of a subtype visible in a predicate should be treated as a "value" rather than as an "object." That prevents use of things like 'Address and 'Size which just cause trouble. However, it highlights the fact that you can't rename a value, which is a bit annoying in some cases, particularly if the current instance is of a composite type. It would seem easy enough to permit renaming of values in an "object renaming." Especially now that we don't require you to specify the type of the thing being renamed, it seems particularly natural to allow essentially any kind of value to be renamed, including named numbers, for example. We already allow renaming of the result of functions, which most folks think of as a "value" anyway, so it is a bit confusing to then find that other things that just happen to be a value cannot be renamed. So I would propose we adjust the wording in the Object Renaming clause as follows: Modify 8.5.1(1): [Redundant: An object_renaming_declaration is used to rename an object {or a value}.] Modify 8.51(4-4.1/2): The renamed entity shall be an object {or a value}. In the case where the type is defined by an access_definition, the type of the renamed [object] {entity} and the type defined by the access_definition: Modify 8.5.1 (6/2): An object_renaming_declaration declares a new view [Redundant: of the renamed [object]{entity}] whose properties are identical to those of the renamed view. [Redundant: Thus, the properties of the renamed [object]{entity} are not affected by the renaming_declaration. In particular, {whether it is a value or an object,} its value {if it is an object,} and whether or not it is a constant{,} are unaffected; similarly, the null exclusion or constraints that apply [to an object] are not affected by renaming (any constraint implied by the subtype_mark or access_definition of the object_renaming_declaration is ignored).] Add an example, after 8.5.1(8): Example of renaming a value: Uno renames One; -- see 3.3.2 **************************************************************** From: Randy Brukardt Sent: Monday, April 27, 2020 7:34 PM Humm. You've been pretty consistent that you have always wanted generic formal parameters and renaming to work the same way. This would be a pretty significant break from that (object renaming currently is equivalent to in out generic formals, but the latter would make no sense for values). I personally have never cared very much about that equivalence, but it has been used in the past to stop otherwise sensible changes, including this one. **************************************************************** From: Tucker Taft Sent: Tuesday, April 28, 2020 8:55 PM > Humm. You've been pretty consistent that you have always wanted > generic formal parameters and renaming to work the same way. This > would be a pretty significant break from that (object renaming > currently is equivalent to in out generic formals, but the latter would > make no sense for values). Well I don't see the big breakage. Constants can't be passed to generic in-out parameter, but they can be renamed. Allowing values to be renamed doesn't mean that they should be allowed as in-out parameters. I think we can safely evaluate this proposal without worrying about whether it breaks the symmetry with generic in-out parameters. > I personally have never cared very much about that equivalence, but it > has been used in the past to stop otherwise sensible changes, > including this one. I don't see the issue here. **************************************************************** From: Randy Brukardt Sent: Tuesday, April 28, 2020 9:10 PM Interesting. So you're admiting that this "principle" is a load of horse manure? It can't be the case that we only ignore a language design principle when it is convenient for you, while continuing to use it to reject other good ideas. The next time this principle comes up, I intend to object as it does not really exist. I do worry that allowing renames of universals (that is, named numbers and the like) may cause some problems with 4.9 and the preference rules of 8.6. Those all were designed with the expectation that renaming wasn't a possibility. But I don't have a specific example, Steve is better at that than me. **************************************************************** From: Tucker Taft Sent: Wednesday, April 29, 2020 6:52 AM > Interesting. So you're admiting that this "principle" is a load of horse > manure? It can't be the case that we only ignore a language design principle > when it is convenient for you, while continuing to use it to reject other > good ideas. What I said is that we already allow renaming of constants, so allowing renaming of values has no impact on this principle, because the generic use of renaming only applies to variables (and subprograms). I think the principle is useful when deciding about the rules that apply to renaming of variables. I don't think it can tell us anything when applying to renaming of things that are not variables. > ... > > I do worry that allowing renames of universals (that is, named numbers and > the like) may cause some problems with 4.9 and the preference rules of 8.6. > Those all were designed with the expectation that renaming wasn't a > possibility. But I don't have a specific example, Steve is better at that > than me. It will be interesting to know if there are issues. Renaming of values of a *non* universal type seems pretty uncontroversial, I would think. We recently allowed 'Image to apply to named numbers, so it seemed natural to consider extending renaming to them as well, but the real goal is to allow renaming of parts of a current instance of a subtype, in a complex predicate. **************************************************************** From: Jeff Cousins Sent: Wednesday, October 28, 2020 4:27 AM Hello. I’m looking at the example in AI12-0226: Max : constant Natural := 10; Ren1 : Natural renames Max; -- Legal. Ren2 : Natural renames Natural'(Max);-- Legal, object. Ren3 : Natural renames Natural(Max); -- Illegal, not object. (A value -- conversion is not an object.) Besides the recent discussion about whether Ren2 : Natural renames Natural'(Max); was legal, is Ren3 : Natural renames Natural(Max); legal as doesn’t the conversion have to be of a tagged type, from 4.6 (5/2) ? {8652/0017} {AI95-00184-01} {AI95-00330-01} A type_conversion whose operand is the name of an object is called a view conversion if both its target type and operand type are tagged, or if it appears in a call as an actual parameter of mode out or in out; other type_conversions are called value conversions. 5.a Ramification: A view conversion to a tagged type can appear in any context that requires an object name, including in an object renaming, the prefix of a selected_component, and if the operand is a variable, on the left side of an assignment_statement. View conversions to other types only occur as actual parameters. Allowing view conversions of untagged types in all contexts seemed to incur an undue implementation burden. **************************************************************** From: Tucker Taft Sent: Thursday, October 29, 2020 7:05 PM Ren3 : Natural renames Natural(Max); -- Illegal, not object. (A value > -- conversion is not an object.) That is now legal as well per AI12-0383-1. The only requirement is that the object/value you are renaming can be denoted by a *name* -- it need not be an object -- it can be a value. ... > legal as doesn’t the conversion have to be of a tagged type, from 4.6 (5/2)? This is legal because of AI12-0383-1. **************************************************************** From: Jeff Cousins Sent: Friday, October 30, 2020 4:45 AM Thanks again Tuck. So I think we're fixing this twice over, adding value conversions to the list of things that are objects, then saying that you can rename values anyway. **************************************************************** From: Randy Brukardt Sent: Friday, October 30, 2020 10:04 PM These aren't quite overlapping changes, since there are other uses that require objects, but clearly renaming was the most important (until the requirement was eliminated). ****************************************************************