Unofficial wish list status.(Jul 2008)

[Jason House]

Steven Schveighoffer Wrote:

> "Jason House" wrote
> > Steven Schveighoffer Wrote:
> >
> >> "Jason House" wrote
> >> > Walter Bright Wrote:
> >> >> The missing ingredient here is what the 'pure' modifier for functions
> >> >> provides. That is the ability to diagnose attempts to alter global 
> >> >> state
> >> >> from within a function that is not supposed to do that. Invariant does
> >> >> not imply pure.
> >> >
> >> >
> >> > That's actually a very key part to my whole point.  There is very 
> >> > little
> >> > difference between pure and invariant functions.  Why do we need a 
> >> > concept
> >> > for both?  Under the assumption that we're adding const to support
> >> > functional programming, I don't understand the motivation for this
> >> > difference.
> >>
> >> You are misunderstanding what an 'invariant' member function is.  The
> >> function itself is not invariant.  It's a function whose 'this' pointer 
> >> is
> >> marked as invariant.
> >
> >
> > It's not that I misunderstand but that I question.  Given the goals of the 
> > const system, invariant functions, as defined, don't make a lot of sense. 
> > They make some sense, but not a lot of sense :)
> 
> They don't make any less sense than declaring invariant variables.  Or 
> declaring invariant parameters.
> 
> Can you see use in the following function signature:
> 
> void f(invariant(somestruct) *x) {...}
> 
> If so, an invariant member function is no different.

Will the fields of somestruct be accessed directly?  If so, there's no change in functionality.  If not, will the invariant functions of somestruct be used to modify global state?  If not, there's not change in functionality...  I don't think what I'm suggesting changes a lot of code.




> I agree that having invariant functions is probably not going to be 
> extremely useful

Are we including invariant functions as an assumed feature that people need?  Walter was recently considering eliminating one use of synchronized statements because there was no real use for it.


> to not allow invariant methods is to make an inconsistency 
> in the type system.  If I can declare a variable is invariant, then I should 
> be able to pass that variable to a function as invariant.

I'm missing something here...  Why couldn't you pass an invariant object as an invariant parameter into a function?


> If there is a 
> special case that you can't pass it to it's own member function, then it is 
> not only inconsistent, but probably makes the compiler more complex for no 
> good reason.  


I've lost your line of reasoning, can you explain more?


> If you don't like invariant functions, don't use them.  I 
> probably won't.


That all depends on how the libraries you use are written.  Hopefully they won't forget to add the pure keyword where it matters ;)