I just got it! (invariant/const)

[Jason House]

Simen Kjaeraas Wrote:

> On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron <caron800 at googlemail.com>  
> wrote:
> 
> > On 09/04/2008, Jason House <jason.james.house at gmail.com> wrote:
> >>  Consider this example:
> >> <snip>
> >
> > Oh well, that's obvious. f() can't call D.invMemberFunc() because
> > D.invMemberFunc() isn't pure. Pure functions can only call other pure
> > functions.
> >
> > You know that. I know that. Why would anyone think it strange?
> 
> I think it is because invMemberFunc is invariant. Many read this as
> "will not change anything", even though it is not what it means.
> 
> -- Simen

That's certainly a piece of it, but it's more than that.  A lot of people talk about pure functions taking invariant data as being enough.  In reality, the invariant nature is only enough when accessing data without member functions.  When member functions are involved, the invariant property is not enough.

While those of use paying attention know that it's not enough, it feels quite strange.  Andrei's slides use multithreading as needing invariance to work.  When pushed, people say that invariance is necessary but not sufficient and requires pure instead.  So multithreading requires pure functions and invariant primitive types.

The current const/invariant stuff has a way of handling member functions that really doesn't make much sense...  It turns out that most invariant functions will also require that they're declared pure... so how much sense  does invariant member functions really make?

I'll toss out the idea that if invariant functions could only access invariant global state (and invariant static members) that they nearly match the pure function definition.  In such a situation, nearly all invariant member functions could be used as part of multi-threaded optimization.