Fully transitive const is not necessary

[Bill Baxter]

Walter Bright wrote:
> Janice Caron wrote:
>> However, I suspect that the following will be OK.
>>
>>     enum g = 42;
>>
>>     pure int f()
>>     {
>>         return g;
>>     }
> 
> Yes, because the value of g can never change.
> 
> The way to think about pure functions is that if the arguments are the 
> same, the result will be the same. This precludes reading any global 
> state that could change, and precludes writing to any global state.
> 
> But global invariants and manifest constants cannot ever change state, 
> and cannot be written to, so using them in a pure function is ok.

So does that mean

   pure int f(const Class c)
   { ...
   }

will *not* be allowed?  Because some part of c *could* change, even if 
it's not f() doing the changing.  I.e. another thread could be changing 
c concurrently.

If so, that seems unnecessarily restrictive to me.  Any side effect or 
indeterminacy of f() in that case is not because of f()'s doing.  So 
f()'s behavior *is* pure even if it takes a const argument.  It's not 
f's fault if the environment it's living in is unstable.

Maybe there need to be two levels of pure?  One says this function by 
itself has no side effects, the other says additionally that the 
function is invariant with respect to the environment.  The former 
category of functions can all be run in parallel safely provided there 
are no other threads modifying the environment simultaneously.  The 
latter category can be run absolutely any time, any order, and any way 
you want, no matter what else is going on with the environment.

--bb