CVS difference for ai12s/ai12-0075-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai12s/ai12-0075-1.txt

--- ai12s/ai12-0075-1.txt	2017/10/12 04:36:52	1.6
+++ ai12s/ai12-0075-1.txt	2018/01/18 07:16:33	1.7
@@ -1,4 +1,4 @@
-!standard 4.9(6)                                  15-10-17    AI12-0075-1/04
+!standard 4.9(6)                                  18-01-05    AI12-0075-1/05
 !standard 4.9(18)
 !class Amendment 13-06-09
 !status work item 13-06-09
@@ -22,40 +22,25 @@
 
 !wording
 
-Replace 4.9(6)
+Add to the definition of static function (i.e. insert as the penultimate
+item of the 4.9 (19-22) list):
 
-  - a function_call whose function_name or function_prefix statically
-    denotes a static function, and whose actual parameters, if any
-    (whether given explicitly or by default), are all static expressions;
-
-with
-
-  - a function_call whose function_name or function_prefix statically
-    denotes a static function, whose actual parameters, if any (whether
-    given explicitly or by default), are all static expressions, and which
-    satisfies an additional condition: either the function_name or
-    function_prefix does not statically denote an expression function
-    or the compile-time evaluation of the call does not fail any
-    language-defined check.
-
-    Note: This means that a call to a static expression function whose
-    (compile-time) evaluation fails a language-defined check is not a
-    static expression (as opposed to being illegal). The motivation for
-    this is to avoid incompatibly introducing legality violations
-    for calls to expression functions occurring in dead code, as in
-     declare
-       N : constant := Pkg1.This - Pkg2.That; -- it happens that N = 0
-       function Divide_By_N (X : Integer) return Integer is (X / N);
-       Y : Integer;
-     begin
-       if N /= 0 then
-          Y := Divide_By_N (1234);
-       end if;
-       ...
-    end;
+  - a static expression function (see 6.8)
+
+Add at the and of the 4.9 "Legality Rules" section:
+
+  AARM Discussion:
+  The preceding "statically unevaluated" rule allows
+       X : constant := (if True then 37 else (1 / 0))
+  but does not allow
+       function If_Then_Else (Flag : Boolean; X, Y : Integer) is
+          (if Flag then X else Y) with Static; -- see 6.8
+       X : constant := If_Then_Else (True, 37, 1 / 0);
+  because evaluation of a function call includes evaluation of
+  all of its actual parameters.
 
-Add just before the definition of "static function" (i.e., just
-before 4.9(18)):
+Introduce a "Static Semantics" section for 6.8 immediately before the
+"Legality Rules" section, containing:
 
   A "potentially static expression" is defined in the same way as a
   static expression except that
@@ -72,181 +57,86 @@
   qualified expressions, membership tests, short circuit control forms,
   conditional expressions, and parenthesized expressions.
 
-  A "static expression function" is defined to be an expression function
+  A "potentially static expression function" is defined to be an
+  expression function
     - whose expression is a potentially static expression; and
     - which contains no calls to itself; and
     - each of whose parameters (if any) is of mode IN and is of a
       static subtype; and
     - whose result subtype is a static subtype; and
-    - to which no precondition or postcondition expression applies.
+    - to which no precondition or postcondition expression applies; and
+    - which is not type invariant enforcing for any type (see 7.3.2); and
+    - which is not a completion.
 
-  AARM Discussion:
-  In the case of an expression_function_declaration which is the
-  completion of an earlier subprogram_declaration, the function is an
-  expression function if and only if the completion is visible.
-  This implies that it is possible for a (view of a) function to be a
-  static expression function if and only if its completion is visible.
-  This is similar to the way that the completion of a deferred constant
-  may be a static constant.
+  The following language-defined representation aspect may be specified
+  for a potentially static expression function.
 
+    Static - The type of aspect Static is Boolean.
+
+  A "static expression function" is defined to be an expression function
+  whose Static aspect is True.
   In addition, an inherited function is defined to be a static expression
   function if the corresponding primitive function of the parent or
-  progenitor type is a static expression function (as viewed at the
-  point of the declaration of the inherited function).
-
-  AARM Discussion:
-  Unlike non-inherited subprograms, all views of a given inherited subprogram
-  always agree with respect to whether the given subprogram is a
-  static expression function.
+  progenitor type is a static expression function.
+  [A static expression function is a static function; see 4.9].
 
-Add to the definition of static function (i.e. as another list item
-at the end of the 4.9 (19-22) list):
+In 7.3.2, add the following at the end of the Static semantics section.
 
-  - a static expression function
+If one or more invariant expressions apply to a nonabstract type T, then
+a subprogram or entry is said to be "type invariant enforcing" for T if
+   - it is the Read or Input stream-oriented attribute of the type T; or
+   - it is declared within the immediate scope of T (or by an instance of a
+     generic unit, and the generic is declared within the immediate scope of
+     type T), and either:
+
+       * has a result with a part of type T; or
+       * has one or more *out* or *in out* parameters with a part of type T; or
+       * has an access-to-object parameter or result whose designated type has
+         a part of type T; or
+       * is a procedure or entry that has an *in* parameter with a part of type
+         T.
+
+   - and either:
+
+       * T is a private type or a private extension and the subprogram or
+         entry is visible outside the immediate scope of type T or overrides
+         an inherited operation that is visible outside the immediate scope
+         of T; or
+       * T is a record extension, and the subprogram or entry is a primitive
+         operation visible outside the immediate scope of type T or overrides
+         an inherited operation that is visible outside the immediate scope
+         of T.
+
+     Each such part of type T is said to be "subject to an invariant check"
+     for T.
+
+In the Dynamic Semantics section, replace 7.3.2(15/4-20/5) with
+
+   An invariant check is checked upon successful return from a call on any
+   subprogram or entry which is type invariant enforcing for T. The check is
+   performed on each part of type T which is subject to an invariant check
+   for T.
 
-Add at the and of the 4.9 "Legality Rules" section:
-
-  AARM Discussion:
-  The preceding "statically unevaluated" rule allows
-       X : constant := (if True then 37 else (1 / 0))
-  but does not allow
-       function If_Then_Else (Flag : Boolean; X, Y : Integer) is
-          (if Flag then X else Y);
-       X : constant := If_Then_Else (True, 37, 1 / 0);
-  because evaluation of a function call includes evaluation of
-  all of its actual parameters.
-
 !discussion
 
-1) This change is incompatible in some cases.
-The following example is currently legal
+The stuff in 7.3.2 (type invariants) is all intended to be semantics-preserving.
+The only goal of this rearrangement is to define the term "type invariant
+enforcing" so that we can say that an expression function which is
+"type invariant enforcing" for some type T is not a potentially static
+expression function. And, of course, the term itself is subject to
+discussion - we might choose a different term.
+
+This version incorporates feedback from the last two meetings so that
+   a) in order for an expression function to be a static function, you
+      have to explicitly ask for it by specifying the Static aspect
+      (a new Boolean aspect).
+
+   b) an expression function which is a completion is never a static
+      function. No view-specific stuff where sometimes it is and
+      sometimes it isn't, depending on whether the completion is visible.
 
-   procedure Foo is
-      function Inc (X : integer) return Integer is (X + 1);
-      subtype S is Integer range 0 .. Inc (3);
-      Y : S := ... ;
-   begin
-      case Y is
-         when  0 .. 33 => ...;
-         when  44 .. 55 => ...;
-         when others => ... ;
-      end case;
-   end;
-
-but will become illegal because with this change Y will have
-a static nominal subtype.
-
-The most significant compatibility issues are addressed via
-the rule that a call to an expression function whose compile-time
-evaluation fails a check is non-static but still legal (as opposed
-to being illegal).
-
-The alternative of defining a new Boolean aspect (perhaps named
-Static_Function) was discussed and not selected.
-
-2) It would be simpler to say that an inherited subprogram is never
-a static expression function.
-
-However, it seems nice to allow things like
-
-  declare
-    package Pkg1 is
-       type T1 is range 1 .. 10;
-       function Wrapping_Inc (X : T1) is
-         (if X = T1'Last then T1'First else T1'Succ (X));
-    end Pkg1;
-
-    package Pkg2 is
-       type T2 is new Pkg1.T1;
-    end Pkg2;
-
-    Named_Number : constant := Pkg2.Wrapping_Inc (3);
-  begin ... end;
-
-by defining the inherited function Pkg2.Wrapping_Inc to
-be a static expression function.
-
-It seems clear that we want to avoid a "characteristics"-like
-situation where a change in the status of the parent type's
-operator causes a change in the status of the inherited operator.
-That's the reason for the "as viewed at the point of ..." wording.
-
-It's not clear whether an inherited function is ever an expression
-function; we might want to consider clarifying that point if we want to
-avoid the situation of a "static expression function" which is not an
-"expression function". [This question might also need to be resolved
-for reasons having nothing to do with this AI because of the special
-treatment of expression functions in the freezing rules.]
-
-3) Do we need to say anything about type invariants? No,
-because if a function has a parameter (or result) of a private type,
-then it's not a static function. But what if it is completed as
-a static expression function after the private type is completed?
-Maybe we need a rule saying that if a type invariant applies to
-a function than the function is not a static expression function
-(like the rule already given for predicates).
-
-4) We could allow a static expression function to have
-an applicable pre/post-condition as long as the condition is a
-potentially static expression. Pre/post conditions for one-part
-(i.e., no forward declaration) expression functions are of very limited
-value, but supporting PPCs might make more sense for two-part functions.
-
-5) We've got the 3.8 rule
-
-    If the discriminant is used to define the constraint of a component, the
-    bounds of an entry family, or the constraint of the parent subtype in a
-    derived_type_definition, then its name shall appear alone as a direct_name
-    (not as part of a larger expression or expanded name).
-
-It might seem tempting to allow (in a component constraint) the case of a
-call to a static function such that all parameters (including, of course,
-defaulted parameters) are either static expressions or names denoting
-discriminants. This would allow, for example, an
-index constraint value of D + 1, where D is a discriminant.
-
-This would introduce some implementation problems.
-
-One property we need for discriminant-dependent component constraint
-expressions is reproducibility - given the same discriminant values
-we must always get the same result. This relaxation of the current rules
-would meet that requirement, but that's not enough.
-
-We also need, given a set of discriminant subtypes, to be able
-to easily calculate the minumum and maximum values that an
-expression might yield (e.g., we need to know how much storage is
-needed when we declare an unconstrained object of a type which has
-an array component with a discriminant-dependent index constraint).
-
-Given something like
-
-    subtype Index is Integer range 0 .. <some non-static expression>;
-    type Rec (Length : Index := 0) is record
-      F : String (1 .. Length);
-    end record;
-    X : Rec;
-
-it is easy to compute (at runtime) the amount of storage required for X.
-If we replace "1 .. Length" in the above example with
-"1 .. Some_Static_Expr_Func (Length)", then this becomes more
-complicated because a static expression function need not be
-monotonic.
-
-Thus, this proposal would lead to implementation problems.
-
-6) Because an expression function can be a completion, one might
-think that a rule is needed to prevent indirect recursion in a
-static expression function. However, no special rule is needed.
-Given
-
-    function F1 (X : Natural);
-    function F2 (X : Natural) is
-      (if X = 0 then 0 else 1 + F1 (X / 2));
-    function F1 (X : Natural) is (F2 (X));
-
-neither of the two functions are static expression functions.
-This is because, as viewed from the point where F2 calls F1,
-F1 is not an expression function.
+   c) an expression function which is subject to a type invariant is
+      never a static function.
 
 !example
 
@@ -578,27 +468,27 @@
 From: Tucker Taft
 Sent: Thursday, October  5, 2017  3:16 PM
 
-> It seems clear that compatibility issues are a major concern 
+> It seems clear that compatibility issues are a major concern
 > associated with this proposal.
 
 Maybe for some folks.  Expression functions are pretty new!
 
 ...
-> There is a solution which satisfies both constraints, although I am 
-> not claiming that it is elegant: we relax the legality rules as per 
-> Bob's proposal but only in the case of a static expression that 
-> includes a call to an expression function. Such an expression could 
-> never currently be static, so this relaxation would not cause us to 
+> There is a solution which satisfies both constraints, although I am
+> not claiming that it is elegant: we relax the legality rules as per
+> Bob's proposal but only in the case of a static expression that
+> includes a call to an expression function. Such an expression could
+> never currently be static, so this relaxation would not cause us to
 > accept something that was previously rejected.
 
 That seems fine to me.
 
 > ...
-> I think we need to invent a term for the property implicitly defined 
+> I think we need to invent a term for the property implicitly defined
 > in the section on type invariants
 >   An invariant is checked upon successful return from any
 >   call on a subprogram or entry that ...
-> 
+>
 > Something like
 >    An entry or subprogram is said to be an "invariant
 >    boundary" entry or subprogram if ...
@@ -613,16 +503,16 @@
 I suppose any term we pick would eventually grow on me... ;-)
 
 ...
-> Other possible names for the new term: "invariant enforcing", 
+> Other possible names for the new term: "invariant enforcing",
 > "invariant checking".
 
 I find these names even muddier...  I would like to describe the concept,
 without talking about what things might happen when crossing that border.
 Sort of like calling the border between two countries an "immigration control
 line."
- 
+
 > ====
-> 
+>
 > Opinions?
 
 See above.
@@ -632,7 +522,7 @@
 From: Steve Baird
 Sent: Thursday, October  5, 2017  3:41 PM
 
->  I would somewhat rather associate the notion of boundary with the 
+>  I would somewhat rather associate the notion of boundary with the
 > type being defined,
 I like that idea too.
 
@@ -658,9 +548,9 @@
 From: Randy Brukardt
 Sent: Thursday, October  5, 2017  3:46 PM
 
-> > It seems clear that compatibility issues are a major concern 
+> > It seems clear that compatibility issues are a major concern
 > > associated with this proposal.
-> 
+>
 > Maybe for some folks.  Expression functions are pretty new!
 
 Two points on this:
@@ -678,15 +568,15 @@
 on expression functions. When that is done, they'd be at risk of running into
 these compatibility issues. [Note to any Janus/Ada customers reading this: I'm
 speaking in the future tense here. :-)]
- 
+
 ...
-> > There is a solution which satisfies both constraints, although I am 
-> > not claiming that it is elegant: we relax the legality rules as per 
-> > Bob's proposal but only in the case of a static expression that 
-> > includes a call to an expression function. Such an expression could 
-> > never currently be static, so this relaxation would not cause us to 
+> > There is a solution which satisfies both constraints, although I am
+> > not claiming that it is elegant: we relax the legality rules as per
+> > Bob's proposal but only in the case of a static expression that
+> > includes a call to an expression function. Such an expression could
+> > never currently be static, so this relaxation would not cause us to
 > > accept something that was previously rejected.
-> 
+>
 > That seems fine to me.
 
 Cool. I predicted to Steve the opposite. (It is a rather clunky rule, and I
@@ -697,7 +587,7 @@
 From: Tucker Taft
 Sent: Thursday, October  5, 2017  6:42 PM
 
-> Roughly speaking, the idea we are trying to capture here is that a 
+> Roughly speaking, the idea we are trying to capture here is that a
 > boundary subprogram for a given private type
 >   a) can see the implementation of the private type; and
 >   b) is callable from places that cannot see the implementation
@@ -741,19 +631,19 @@
 Sent: Thursday, October  5, 2017  8:05 PM
 
 > Good point about access parameters.
-> 
+>
 > And even for others, I see your point.
-> 
-> There are advantages to ignoring the parameter mode completely (as 
-> opposed to special rules for in-mode non-access parameters) and I 
-> don't see any disadvantages, even if no runtime check is performed in 
+>
+> There are advantages to ignoring the parameter mode completely (as
+> opposed to special rules for in-mode non-access parameters) and I
+> don't see any disadvantages, even if no runtime check is performed in
 > that case.
 
-Right.  This is another reason I would be reluctant to include the word 
+Right.  This is another reason I would be reluctant to include the word
 "invariant" in the term we end up using.
 
-> And of course when I talked about a parameter/result of the private 
-> type, I should have been talking about a parameter/result of a type 
+> And of course when I talked about a parameter/result of the private
+> type, I should have been talking about a parameter/result of a type
 > that has a part which is of that type.
 
 You could argue that boundary subprograms need not have any parameters or
@@ -763,7 +653,7 @@
 there.  SPARK as of today (prior to "safe" pointers) doesn't have this
 problem, but presumably in Ada we do have that situation, and SPARK with
 safe pointers might have it as well.  So I think the parameter profile might
-be irrelevant once you start having pointers.  
+be irrelevant once you start having pointers.
 
 But now if we bring this back to expression functions -- can they be static
 if they have any parameters of an access type?  And I have lost track of what
@@ -779,12 +669,12 @@
 Sent: Thursday, October  5, 2017  8:21 PM
 
 ...
-> But now if we bring this back to expression functions -- can they be 
+> But now if we bring this back to expression functions -- can they be
 > static if they have any parameters of an access type?
->  And I have lost track of what this whole thing was about -- why are 
+>  And I have lost track of what this whole thing was about -- why are
 > invariant checks a problem?
 
-From memory, we don't want any checks that might fail in a static function 
+From memory, we don't want any checks that might fail in a static function
 call. We disallow predicates, and Steve decided we needed to do the same
 for any invariant checks.
 
@@ -804,7 +694,7 @@
 
 This surprises me.  What is the purpose of a static function if you don't
 know it is static and cannot use it as one?  At least with this AI, the only
-way you know that an expression function is a static function is by looking 
+way you know that an expression function is a static function is by looking
 at its defining expression.  I suppose if there were an aspect "Static" or
 equivalent, then you could postpone the "body" of the expression function to
 the private part.  Am I missing something?
@@ -814,22 +704,22 @@
 From: Randy Brukardt
 Sent: Thursday, October  5, 2017  10:01 PM
 
-> This surprises me.  What is the purpose of a static function if you 
+> This surprises me.  What is the purpose of a static function if you
 > don't know it is static and cannot use it as one?
 
 One could argue "approximately the same as any other user-defined static
 function", but that's a discussion for a different time.
 
-... > At least with this AI, the only way you know that an expression 
-> function is a static function is by looking at its defining 
-> expression.  I suppose if there were an aspect "Static" or equivalent, 
-> then you could postpone the "body" of the expression function to the 
+... > At least with this AI, the only way you know that an expression
+> function is a static function is by looking at its defining
+> expression.  I suppose if there were an aspect "Static" or equivalent,
+> then you could postpone the "body" of the expression function to the
 > private part.  Am I missing something?
 
 There surely should be a "Static_Possible" aspect, which among other things
 would allow deferring the expression elsewhere (probably not to a body, though,
 as the compiler has to be able to see a static expression that it is
-evaluating). It certainly would be needed should we ever try to expand static 
+evaluating). It certainly would be needed should we ever try to expand static
 processing to user-defined static expressions. (Jeff told me privately that
 the UK would like to see static expression processing regularized. I think
 we've already rejected that idea for this cycle, but I think we need to leave
@@ -840,19 +730,19 @@
 From: Tucker Taft
 Sent: Thursday, October  5, 2017  10:57 PM
 
-> There surely should be a "Static_Possible" aspect, which among other 
-> things would allow deferring the expression elsewhere (probably not to 
-> a body, though, as the compiler has to be able to see a static 
+> There surely should be a "Static_Possible" aspect, which among other
+> things would allow deferring the expression elsewhere (probably not to
+> a body, though, as the compiler has to be able to see a static
 > expression that it is evaluating).
 
-I am dubious.  Static expressions can affect legality, so you really have to 
+I am dubious.  Static expressions can affect legality, so you really have to
 know what the function is computing.  There really can't be any "abstraction"
 here to speak of.
 
-> It certainly would be needed should we ever try to expand static 
-> processing to user-defined static expressions. (Jeff told me privately 
-> that the UK would like to see static expression processing 
-> regularized. I think we've already rejected that idea for this cycle, 
+> It certainly would be needed should we ever try to expand static
+> processing to user-defined static expressions. (Jeff told me privately
+> that the UK would like to see static expression processing
+> regularized. I think we've already rejected that idea for this cycle,
 > but I think we need to leave the possibility open.)
 
 I think you are talking about a completely different AI than this one.  Given
@@ -865,8 +755,8 @@
 Sent: Thursday, October  5, 2017  11:11 PM
 
 ...
-> I think you are talking about a completely different AI than this one.  
-> Given the current AI, there seems no particular value to allowing a 
+> I think you are talking about a completely different AI than this one.
+> Given the current AI, there seems no particular value to allowing a
 > static expression function to be a completion.
 
 Yes, a different (and future) AI. But I don't want this AI to prevent that AI
@@ -877,7 +767,7 @@
 From: Tucker Taft
 Sent: Thursday, October  5, 2017  11:04 PM
 
-> Yes, a different (and future) AI. But I don't want this AI to prevent 
+> Yes, a different (and future) AI. But I don't want this AI to prevent
 > that AI from being possible.
 
 Right.  But being *more* restrictive than absolutely necessary is our usual
@@ -910,8 +800,8 @@
 From: Steve Baird
 Sent: Friday, October  6, 2017  11:26 AM
 
-> It is inconsistent with our treatment of deferred constants (because a 
-> use of a deferred constant can be static if the completion is 
+> It is inconsistent with our treatment of deferred constants (because a
+> use of a deferred constant can be static if the completion is
 > visible),
 
 Do we decide whether an expression function is a static expression function
@@ -934,12 +824,12 @@
 From: Randy Brukardt
 Sent: Monday, October  9, 2017  7:07 PM
 
->> There surely should be a "Static_Possible" aspect, which among other 
->> things would allow deferring the expression elsewhere (probably not 
->> to a body, though, as the compiler has to be able to see a static 
+>> There surely should be a "Static_Possible" aspect, which among other
+>> things would allow deferring the expression elsewhere (probably not
+>> to a body, though, as the compiler has to be able to see a static
 >> expression that it is evaluating).
 
->I am dubious.  Static expressions can affect legality, so you really 
+>I am dubious.  Static expressions can affect legality, so you really
 >have to know what the function is computing.  There really can't be any
 >"abstraction" here to speak of.
 
@@ -949,23 +839,23 @@
 with.
 
 ...
-> >>> It certainly would be needed should we ever try to expand static 
-> >>> processing to user-defined static expressions. (Jeff told me 
-> >>> privately that the UK would like to see static expression 
-> >>> processing regularized. I think we've already rejected that idea 
-> >>> for this cycle, but I think we need to leave the possibility 
+> >>> It certainly would be needed should we ever try to expand static
+> >>> processing to user-defined static expressions. (Jeff told me
+> >>> privately that the UK would like to see static expression
+> >>> processing regularized. I think we've already rejected that idea
+> >>> for this cycle, but I think we need to leave the possibility
 > >>> open.)
-> >> 
-> >> I think you are talking about a completely different AI than this 
-> >> one.  Given the current AI, there seems no particular value to 
+> >>
+> >> I think you are talking about a completely different AI than this
+> >> one.  Given the current AI, there seems no particular value to
 > >> allowing a static expression function to be a completion.
-> > 
-> > Yes, a different (and future) AI. But I don't want this AI to 
+> >
+> > Yes, a different (and future) AI. But I don't want this AI to
 > > prevent that AI from being possible.
-> 
-> Right.  But being *more* restrictive than absolutely necessary is our 
-> usual approach.  By requiring static expression functions to be 
-> defined where they are declared, we are keeping this AI simpler, and 
+>
+> Right.  But being *more* restrictive than absolutely necessary is our
+> usual approach.  By requiring static expression functions to be
+> defined where they are declared, we are keeping this AI simpler, and
 > allowing ourselves to relax the restrictions later.
 
 Such a future AI would have to have a way (almost certainly an aspect) to mark
@@ -982,18 +872,18 @@
 From: Tucker Taft
 Sent: Monday, October  9, 2017  8:45 PM
 
->> Right.  But being *more* restrictive than absolutely necessary is our 
->> usual approach.  By requiring static expression functions to be 
->> defined where they are declared, we are keeping this AI simpler, and 
+>> Right.  But being *more* restrictive than absolutely necessary is our
+>> usual approach.  By requiring static expression functions to be
+>> defined where they are declared, we are keeping this AI simpler, and
 >> allowing ourselves to relax the restrictions later.
-> 
-> Such a future AI would have to have a way (almost certainly an aspect) 
-> to mark completions that are static functions. (A "generalization" 
-> proposal that doesn't support private types is not really fixing 
-> anything, IMHO.) An AI that has some sort of automatic static 
-> functions is going to conflict with that future AI, as there would be 
-> a mismash of automatic and declared static functions, and probably 
-> conflicts in some cases. Automatic static functions is a dead-end that 
+>
+> Such a future AI would have to have a way (almost certainly an aspect)
+> to mark completions that are static functions. (A "generalization"
+> proposal that doesn't support private types is not really fixing
+> anything, IMHO.) An AI that has some sort of automatic static
+> functions is going to conflict with that future AI, as there would be
+> a mismash of automatic and declared static functions, and probably
+> conflicts in some cases. Automatic static functions is a dead-end that
 > would pretty much prevent any further changes to static processing.
 
 I could see adding an aspect to claim that something is a static function,
@@ -1018,11 +908,11 @@
 Sent: Monday, October  9, 2017  9:21 PM
 
 ...
-> But I still don't get how you can complete a static function in a 
-> private part or a body, if it is going to be static outside the 
-> package as well.  Because the *values* returned by the function can 
-> really matter to the caller, as they determine legality, and in some 
-> weird cases, can even determine the type (e.g. A'First(N) where "N" is 
+> But I still don't get how you can complete a static function in a
+> private part or a body, if it is going to be static outside the
+> package as well.  Because the *values* returned by the function can
+> really matter to the caller, as they determine legality, and in some
+> weird cases, can even determine the type (e.g. A'First(N) where "N" is
 > a static expression function).
 
 I don't get this obsession with values. The first thing an Ada programmer
@@ -1037,8 +927,8 @@
 your program unless the compiler rejects them. That certainly would be the
 case here.
 
-> But I was getting the impression you wanted the "I_Am_Static" 
-> aspect on the visible declaration of the function, but not provide the 
+> But I was getting the impression you wanted the "I_Am_Static"
+> aspect on the visible declaration of the function, but not provide the
 > body there as well.  That is what I don't understand...
 
 What about "abstraction" do you not understand?? Why you think these functions
@@ -1053,5 +943,84 @@
 what else could they possibly be good for?? As I previously said, if they
 don't provide abstraction, then they aren't providing anything at all, and we
 should simply forget this idea.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Wednesday, January  5, 2018  6:43 PM
+
+Another iteration of this AI. [This is version /05 of this AI - ED.]
+
+We address all the compatibility issues by saying that you don't get a static
+expression function unless you ask for it by specifying a new aspect (named
+Static).
+
+[At some later date, we might consider defining a configuration pragma which
+says that the default value of the Static aspect of a potentially static
+expression function is True, not False. That's not currently part of this AI.]
+
+We address all the confusion associated with having a function sometimes be a
+static function and sometimes not (depending on whether the expression
+function completion is visible) by saying that an expression function which is
+a completion is never a static function. Thus, all views of a function agree
+on this point.
+
+We address the interactions with type invariants by making a textually large
+but semantically small change to type invariants (no change to type invariants
+except that we get a new term defined to identify a boundary subprogram).
+
+Feedback, as always, is appreciated.
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Friday, January 12, 2018  7:15 AM
+
+Thanks Steve.
+
+"In 7.3.2, add the following at the end of the Static semantics section.
+
+
+If one or more invariant expressions apply to a nonabstract type T, then
+a subprogram or entry is said to be "type invariant enforcing" for T if
+   - it is the Read or Input stream-oriented attribute of the type T; or"
+
+It seems strange to think of an attribute as a subprogram or entry – would
+attribute reference be better?
+
+You’ve lost the words added by AI12-0193 (i.e. "In the case of a call to a
+protected operation, the check is performed before the end of the protected
+action. In the case of a call to a task entry, the check is performed before
+the end of the rendezvous."
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 12, 2018  11:27 AM
+
+...
+> It seems strange to think of an attribute as a subprogram or entry – would
+> attribute reference be better?
+
+We use the terminology Steve is using in general.  See the definition of
+'Write, for example:
+
+"For every subtype S of a specific type T, the following attributes are defined.
+ S'Write
+     S'Write denotes a procedure with the following specification: ..."
+
+***************************************************************
+
+From: Steve Baird
+Sent: Friday, January 12, 2018  12:27 PM
+
+> You’ve lost the words added by AI12-0193 (i.e. “In the case of a call
+> to a protected operation, the check is performed before the end of the
+> protected action. In the case of a call to a task entry, the check is
+> performed before the end of the rendezvous.”
+
+Good catch! I agree that we don't want to delete that sentence.
+The changes 7.3.2 are intended to introduce the definition of a new term and
+otherwise be semantics-preserving.
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent