!standard 4.9(8) 20-03-12 AI12-0368-1/03 !standard 4.9(12.1/3) !standard 4.9(17) !standard 6.1.1(24.2/5) !standard 6.1.1(24.3/5) !standard 6.1.1(24.4/5) !standard 6.1.1(24.5/5) !standard C.4(9) !class Amendment 20-03-05 !status Amendment 1-2012 20-03-11 !status ARG Approved 14-0-0 20-03-11 !status work item 20-03-05 !status received 20-02-20 !priority Low !difficulty Easy !subject Declare expressions can be static !summary The term "statically names" is defined in 4.9 for more general use. Declare expressions can be static so long as nothing in them requires any runtime evaluation, and the body_expression is static. The prefix of an array attribute can be anything that is "statically named". Preelaboration is required for objects that are statically named. !problem Declare expressions (4.5.9) are not listed in the static expression section (4.9). It would seem a shame if a static expression would lose its static-ness if it was refactored into a declare expression with the same content. We allow static expression functions to be used in static expressions, and declare expressions seem quite similar as far as introducing names which are then used in an expression. !proposal (See Summary.) !wording Modify 4.9(8): * an attribute_reference whose prefix statically [denotes]{names} a statically constrained array object or array subtype, and whose attribute_designator is First, Last, or Length, with an optional dimension; Add after 4.9(12.1/3): * a declare_expression whose body_expression is static and each of whose declarations, if any, is either the declaration of a static constant or is an object_renaming_declaration with an object_name that statically names the renamed object; Add after 4.9(17): A name *statically names* an object if it: * statically denotes the declaration of an object Redundant[(possibly through one or more renames)]; AARM Proof: Follows from the definition of statically denotes. * is a selected_component whose prefix statically names an object, there is no implicit dereference of the prefix, and the selector_name names a component that does not depend on a discriminant; or AARM Reason: We disallow components that depend on a discriminant so that no discriminant checks are needed to evaluate the selected_component. * is an indexed_component whose prefix statically names an object, there is no implicit dereference of the prefix, the object is statically constrained, and the index expressions of the object are static and have values that are within the range of the index constraint. [Editor's note: The part about implicit dereference was missing here in the 6.1.1 wording. Since a "null constraint" (that is, no constraint at all) is considered statically constrained, object of most access types would qualify for the original rule, which is not what we want.] For an entity other than an object, a name statically names an entity if the name statically denotes the entity. Delete 6.1.1(24.2-5/5). [It is moved to 4.9 as above.] Modify C.4(9): * any name that is not part of a static expression is an expanded name or direct_name that statically {names}[denotes] some entity; !discussion We do not want refactoring a static expression to use a declare expression with the same contents (semantically) to become non-static, so a definition for static declare expressions is needed. We use "statically names" in these rules to allow them maximum flexibility. See AI12-0369-1 for an example as to why wrapping an object in a record might be desirable. We checked all of the uses of "statically denotes" in the Standard, and the only other cases that could use "statically names" are associated with various tasking restrictions (see AI12-0369-1) and a rule in C.4. All of the other rules are "statically denoting" entities that are not objects. We also change that rule in this AI. Since the term "statically names" is being used more generally, we move it near the similar definition of "statically denotes". We also extend it to work on non-objects, so that it can be used in place of "statically denotes" without rearranging the rest of the wording. !corrigendum 4.9(8) @drepl @xbullet whose @fa statically denotes a statically constrained array object or array subtype, and whose @fa is First, Last, or Length, with an optional dimension;> @dby @xbullet whose @fa statically names a statically constrained array object or array subtype, and whose @fa is First, Last, or Length, with an optional dimension;> !corrigendum 4.9(12.1/3) @dinsa @xbullet all of whose @fas, @i@fas, and @i@fas are static expressions;> @dinst @xbullet whose @i@fa is static and each of whose declarations, if any, is either the declaration of a static constant or is an @fa with an @i@fa that statically names the renamed object;> !corrigendum 4.9(17) @dinsa @xbullet with a @fa that statically denotes the renamed entity.> @dinss A @fa @i an object if it: @xbullet @xbullet whose prefix statically names an object, there is no implicit dereference of the prefix, and the @fa names a component that does not depend on a discriminant; or> @xbullet whose prefix statically names an object, there is no implicit dereference of the prefix, the object is statically constrained, and the index expressions of the object are static and have values that are within the range of the index constraint.> For an entity other than an object, a @fa statically names an entity if the @fa statically denotes the entity. !corrigendum 6.1.1(24/3) !comment No change here, just need a conflict. @drepl @xbullet other than the first of a membership operation.> @dby @xbullet other than the first of a membership operation.> !corrigendum C.4(9) @drepl @xbullet that is not part of a static expression is an expanded name or @fa that statically denotes some entity;> @dby @xbullet that is not part of a static expression is an expanded name or @fa that statically names some entity;> !ASIS No ASIS change. !ACATS test ACATS B- and C-Tests are needed to check that the declare expressions can be static, and are not static if the conditions aren't met. An ACATS C-Test should be constructed to check that array prefixes can be "statically named" rather than just "statically denoted". !appendix From: Tucker Taft Sent: Monday, February 24, 2020 9:09 AM I just happened to notice that "declare" expressions (4.5.9) are not listed in the static expression section (4.9). It would seem a shame if a static expression would lose its static-ness if it was refactored into a declare expression with the same content. We allow static expression functions to be used in static expressions now, and declare expressions seem quite similar as far as introducing names which are then used in an expression. So perhaps we should add something like the following after 4.9(12.1/3): * a declare_expression whose body_expression is static and each of whose declarations, if any, is either the declaration of a static constant or is an object_renaming_declaration with a name that statically names the renamed object; **************************************************************** From: Tucker Taft Sent: Monday, February 24, 2020 9:15 AM On a related note, I wonder whether paragraph 8 of 4.9 should be shifted to use the "statically names" terminology: * an attribute_reference whose prefix statically [denotes]{names} a statically constrained array object or array subtype, and whose attribute_designator is First, Last, or Length, with an optional dimension; Also, I wonder whether we shouldn't move "statically names" from 6.1.1 to 4.9, where we define "statically denotes." It is a bit odd for "statically names" to be in the pre/postcondition section. **************************************************************** From: Richard Wai Sent: Monday, February 24, 2020 11:07 AM Great catch in both accounts! I agree that these are desirable changes. **************************************************************** From: Steve Baird Sent: Monday, February 24, 2020 12:30 PM > ... So perhaps we should add something like the following after 4.9(12.1/3): > > * a declare_expression whose body_expression is static and each of > whose declarations, if any, is either the declaration of a static > constant or is an object_renaming_declaration with a name that > statically names the renamed object; Looks good to me. > On a related note, I wonder whether paragraph 8 of 4.9 should be shifted to >use the "statically names" terminology: > > * an attribute_reference whose prefix statically [denotes]{names} a > statically constrained array object or array subtype, and whose > attribute_designator is First, Last, or Length, with an optional > dimension; Also looks good. Because declare expressions are new, we don't care about the compatibility issues associated with reclassifying a non-static expression as static (there are issues relating both to legality checks and to real arithmetic precision). > Also, I wonder whether we shouldn't move "statically names" from 6.1.1 to > 4.9, where we define "statically denotes." It is a bit odd for "statically > names" to be in the pre/postcondition section. Very good point. When we introduce a new term and it is used in only one place, it makes sense to define the term near that single use. If we later start using the term in more places, we should consider moving the definition. Note that this guideline wasn't followed (I plead guilty) in the recent ARG discussion of adding another use of "statically names" in the context of defining "pure-barrier-eligible". **************************************************************** From: Gary Dismukes Sent: Monday, February 24, 2020 1:04 PM > Also, I wonder whether we shouldn't move "statically names" from 6.1.1 to > 4.9, where we define "statically denotes." It is a bit odd for "statically > names" to be in the pre/postcondition section. Yes, definitely move it to 4.9. **************************************************************** From: Randy Brukardt Sent: Monday, March 2, 2020 10:32 PM > So perhaps we should add something > like the following after 4.9(12.1/3): > > * a declare_expression whose body_expression is static and each of > whose declarations, if any, is either the declaration of a static > constant or is an object_renaming_declaration with a name that > statically names the renamed object; I agree with the basic question and concept, but I have to wonder about the last part. The only object names allowed in a static expression are the names of static constants. The above wording seems to allow a renaming that statically names a variable. I suppose it wouldn't be harmful, per-se, but such a renaming would be completely useless. Note that renamings can be static constants, so we probably shouldn't be mentioning them separately. * a declare_expression whose body_expression is static and each of whose declarations, if any, is the declaration of a static constant (which might be a stand-alone constant or a renaming declaration); Secondly, "statically naming" a constant component doesn't make it a static constant (which is a concept declared by 4.9(24/5)), since a "static constant" has to be a stand-alone object (since it is required to be declared by a full constant declaration and in particular not a component. (The wording in 4.9(24/5) does not include "part"!) So even for constants the original wording doesn't work, since the renaming still wouldn't be allowed in a static expression unless it was a static constant by 4.9(24/5) - which doesn't allow static naming. I don't see any point in allowing stuff to be declared in a static expression that can't be referenced in the expression. If we're going to allow unusable stuff, it's not clear why we're allowing some renamings and not similar constants. But unused declarations are usually removed when detected, is there a good reason for this to be different? So I think if we want to allow static renaming more generally as is suggested here, we need to do that (somehow) in the definition of static constant, presumably by moving some of the static naming stuff there. But I'm not really sure how that would work, we'd need to get a value from an aggregate in such a case. I don't have any problem with the other suggestions (moving "statically names" here, and using it in the array attribute rule), as well as Tucker's (private) suggestion to use "statically names" in C.4(9). **************************************************************** From: Tucker Taft Sent: Tuesday, March 3, 2020 3:57 AM ... > I agree with the basic question and concept, but I have to wonder > about the last part. The only object names allowed in a static > expression are the names of static constants. The above wording seems > to allow a renaming that statically names a variable. I suppose it > wouldn't be harmful, per-se, but such a renaming would be completely > useless. Note that renamings can be static constants, so we probably > shouldn't be mentioning them separately. You can get a static expression by getting the 'First or 'Last of a statically-constrained variable array (RM 4.9(8)). That is what I had in mind for why a static renaming of a variable would be useful. ... > Secondly, "statically naming" a constant component doesn't make it a > static constant (which is a concept declared by 4.9(24/5)), since a > "static constant" has to be a stand-alone object (since it is required > to be declared by a full constant declaration and in particular not a component. > (The wording in 4.9(24/5) does not include "part"!) So even for > constants the original wording doesn't work, since the renaming still > wouldn't be allowed in a static expression unless it was a static > constant by 4.9(24/5) - which doesn't allow static naming. Again, the point was to allow referring to 'First/'Last of a statically-constrained component. > I don't see any point in allowing stuff to be declared in a static > expression that can't be referenced in the expression. If we're going > to allow unusable stuff, it's not clear why we're allowing some > renamings and not similar constants. But unused declarations are > usually removed when detected, is there a good reason for this to be > different? See above w.r.t statically-constrained array variables. **************************************************************** From: Randy Brukardt Sent: Thursday, March 5, 2020 10:38 PM ... > > I agree with the basic question and concept, but I have to wonder > > about the last part. The only object names allowed in a static > > expression are the names of static constants. The above wording > > seems to allow a renaming that statically names a variable. I > > suppose it wouldn't be harmful, per-se, but such a renaming would be > > completely useless. Note that renamings can be static constants, so > > we probably shouldn't be mentioning them separately. > > You can get a static expression by getting the 'First or 'Last of a > statically-constrained variable array (RM 4.9(8)). > That is what I had in mind for why a static renaming of a variable > would be useful. OIC. Allowing all variables is overkill, since anything other than an array variable is useless. So something like: * a declare_expression whose body_expression is static and each of whose declarations, if any, is either the declaration of a static constant or is an object_renaming_declaration with a name that statically names an array object; might be better. But it's certainly not as clear-cut as I was thinking. And this version is slightly confusing, since a renaming of a static constant is covered by the first part. Probably would need an AARM note for that: AARM Ramification: An object_renaming_declaration that renames a static constant is itself a static constant, so it is also allowed by this rule. Or we could use a parenthetical remark instead: * a declare_expression whose body_expression is static and each of whose declarations, if any, is either the declaration of a static constant (which might be a stand-alone constant or a renaming declaration) or is an object_renaming_declaration with a name that statically names an array object; The need for the AARM note (or the longer parenthetical remark) makes it less of an improvement than I originally hoped. ---- Another point I think came up elsewhere (but I haven't found where yet, it's definitely not in this thread). That is, when we change 4.9(8) to: * an attribute_reference whose prefix statically names a statically constrained array object or array subtype, and whose attribute_designator is First, Last, or Length, with an optional dimension; we now have wording that is talking about "statically names a ... array subtype". But the original definition of "statically names" only applies to objects. We could complicate this wording by using the correct term on each thing: * an attribute_reference whose prefix statically names a statically constrained array object or statically denotes a statically constrained array subtype, and whose attribute_designator is First, Last, or Length, with an optional dimension; but this is a lot longer. So I added the following after the existing definition of "statically names". For other kinds of entities, a name statically names an entity if the name statically denotes the entity. "other kinds" is a bit vague but since it follows the bullets about "statically names an object if" it seemed good enough. I suppose we could use something like: For nonobject entities, a name statically names an entity if the name statically denotes the entity. but I'm no fan of "non"words. **************************************************************** From: Tucker Taft Sent: Friday, March 6, 2020 9:23 AM ... > Or we could use a parenthetical remark instead: > > * a declare_expression whose body_expression is static and each of > whose declarations, if any, is either the declaration of a static > constant (which might be a stand-alone constant or a renaming > declaration) or is an object_renaming_declaration with a name that > statically names an array object; > > The need for the AARM note (or the longer parenthetical remark) makes > it less of an improvement than I originally hoped. I don't see the point of restricting it to array objects. Presumably the programmer will not waste time putting renames into a declare expression that aren't going to be used in later declarations or in the expression. So why be picky here? The key point is we don't want any declarations that require run-time elaboration, since that won't work for a static expression, and "statically names" gives us that. And who knows, some day we might have other sorts of static attributes. > > ---- > > Another point I think came up elsewhere (but I haven't found where > yet, it's definitely not in this thread). > > That is, when we change 4.9(8) to: > > * an attribute_reference whose prefix statically names a > statically constrained array object or array subtype, and whose > attribute_designator is First, Last, or Length, with an optional > dimension; > > we now have wording that is talking about "statically names a ... > array subtype". But the original definition of "statically names" only > applies to objects. Yes, I noticed this in another (non-Ada-Comment) thread, and made essentially the same suggestion you have below: "Another item that came to mind when looking at the definition of "statically names" is that it only is defined for objects. I would think we might want to use the term more generally, with it meaning "statically denotes" for things other than objects, and have the additional ability to denote subcomponents for objects." (24-Feb-2020, 4:31PM EST, "Pure_Barriers restriction relaxation") ... > I suppose we > could use something like: > > For nonobject entities, a name statically names an entity if the name > statically denotes the entity. > > but I'm no fan of "non"words. I am a nonfan as well. ;-) **************************************************************** From: Randy Brukardt Sent: Friday, March 6, 2020 2:29 PM Humm. Maybe better than either would be: For an entity that is not an object, a name statically names an entity if the name statically denotes the entity. or: For an entity other than an object, a name statically names an entity if the name statically denotes the entity. Rather than the vague "other kinds". Thoughts? **************************************************************** From: Tucker Taft Sent: Friday, March 6, 2020 2:47 PM Agreed. Either is better; I slightly prefer the second one ("other than an object"). ****************************************************************