!standard 4.9(8)                                     20-03-05  AI12-0368-1/01
!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 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 a 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, 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 other kinds of entities, 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 (semantically) contents 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.

!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.

****************************************************************