On Tue, 20 Oct 2009 11:57:05 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2009-10-20 11:44:00 -0400, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
On Tue, 20 Oct 2009 08:36:14 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2009-10-20 08:16:01 -0400, "Steven Schveighoffer"
<schvei...@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
