Communicating between in and out contracts

[Steven Schveighoffer]

On Tue, 20 Oct 2009 11:57:05 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-10-20 11:44:00 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> On Tue, 20 Oct 2009 08:36:14 -0400, Michel Fortin   
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2009-10-20 08:16:01 -0400, "Steven Schveighoffer"   
>>> <schveiguy at yahoo.com> said:
>>>
>>>> Incidentally, shouldn't all access to the object in the in contract  
>>>> be   const by default anyways?
>>>  Hum, access to everything (including global variables, arguments),  
>>> not  just the object, should be const in a contract. That might be  
>>> harder to  implement though.
>>  Yeah, you are probably right.  Of course, a const function can still  
>> alter  global state, but if you strictly disallowed altering global  
>> state, we are  left with only pure functions (and I think that's a  
>> little harsh).
>
> Not exactly. Pure functions can't even read global state (so their  
> result can't depend on anything but their arguments), but it makes  
> perfect sense to read global state in a contract. What you really need  
> is to have a const view of the global state. And this could apply to all  
> asserts too.

Yes, but what I'm talking about is "what functions can you call while in a  
contract."  Access to data should be const as you say.  But if you follow  
that logic to the most strict interpretation, the only "safe" functions to  
allow are pure functions.

i.e.:

int x;

class C
{
   void foo()
   in
   {
     x = 5; // I agree this should be an error
     bar(); // ok?
   }
   {}

   void bar() const
   {
     x = 5;
   }
}

-Steve