Unofficial wish list status.(Jul 2008)

[Don]

Steven Schveighoffer wrote:
> "Don" wrote
>> 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.
>> I think it is quite different. The member function is defined inside the 
>> class.
>>
>> Think what it means for the 'this' parameter to be invariant. Unlike 
>> const, it's not conditional. An invariant instance can only call invariant 
>> and const member functions; it can never call mutable member functions. 
>> Likewise, a non-invariant instance can never call invariant member 
>> functions.
>> Seems to me, that you've actually defined 2 classes. There could, for 
>> example, be completely different vtables for invariant vs mutable 
>> instances.
> 
> With invariant functions, what you are defining is a contract for that 
> member function.  The contract states that the object passed to the function 
> as the 'this' pointer must be invariant.  Let's not forget that member 
> functions are simply functions which require you to pass the object.  The 
> only 'special' part of it is the way you write the function call.

There's another difference. The person writing a member function is 
always the same person who wrote the class. They've made a conscious 
design decision that this class can be used as an invariant class (Not 
all classes can be used in this way, in fact most cannot).


> There is no reason you need to define multiple classes.  You are just 
> defining more functions that take a different argument type as the 'this' 
> pointer.  I don't see why it's so confusing to define those functions in the 
> same class as the mutable functions.

My gut feel is that mixing mutable and invariant functions in the one 
class would be an indication of poor design. Which is why I'd be very 
interested in use cases.