Unofficial wish list status.(Jul 2008)

Steven Schveighoffer schveiguy at yahoo.com
Thu Jul 24 07:21:20 PDT 2008


"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 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.

Personally, I probably will only ever write const functions, because I don't 
see myself using invariant classes very much.  But it could be a source of 
optimization.  For example, if there is member data used in the function 
that could be changing, even a const function must synchronize the data.  If 
the function is invariant, the coder does not have to synchronize, and saves 
the cost of that.

-Steve 





More information about the Digitalmars-d mailing list