Version 1.3 of ai12s/ai12-0368-1.txt

Unformatted version of ai12s/ai12-0368-1.txt version 1.3
Other versions for file ai12s/ai12-0368-1.txt

!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)
Replace the paragraph:
by:
!corrigendum 4.9(12.1/3)
Insert after the paragraph:
!corrigendum 4.9(17)
Insert after the paragraph:
the new paragraphs:
A name statically names an object if it:
For an entity other than an object, a name statically names an entity if the name statically denotes the entity.
!corrigendum 6.1.1(24/3)
!comment No change here, just need a conflict.
@drepl @xbullet<a @fa<membership_choice> other than the first of a membership operation.> @dby @xbullet<a @fa<membership_choice> other than the first of a membership operation.>
!corrigendum C.4(9)
Replace the paragraph:
by:
!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").

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

Questions? Ask the ACAA Technical Agent