On 2009-10-20 12:04:20 -0400, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
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;
}
}
When you try to write to x yes it's an error. But if you were reading x
it should not be an error. Basically inside the contract a global like
x should be seen as const(int) just like the object should be seen as
const(C).
Pure functions are somewhat alike, but are more restrictive since you
can only access immutable globals. So what we need is semi-pure
functions that can see all the globals as const data, or in other terms
having no side effect but which can be affected by their environment.
Another function qualifier, isn't it great! :-)
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
