Unofficial wish list status.(Jul 2008)

[Steven Schveighoffer]

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

You are suggesting that invariant functions simply be illegal, and pure 
functions not.  I am saying that you are leaving a hole in the type system 
by doing that.  It is analogous to saying, if a function has any invariant 
parameters, those functions should be marked pure, and all parameters should 
be marked invariant.  I can see many places where some parameters could be 
invariant and some not.  Pure functions (as Walter envisions them) require 
ALL invariant parameters.

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

I'm saying if I can make any parameter invariant, I should be able to make 
the 'this' parameter invariant.  Regardless of whether the function is pure 
or not.  This is all an invariant function is.  To not do this makes the 
type system inconsistent in that you can apply invariant to all types except 
the parameter named 'this' on a member function.  Why separate that out, 
especially when it's already implemented?

>> 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?

This is what you are trying to prevent (passing of an invariant object as an 
invariant parameter).  You are singling out the parameter named 'this' to 
prevent it on.

>
>
>> 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?

Maybe my above comments have done so, but here is a 'proof' of sorts.

Let's say invariant functions are not allowed, but you can declare invariant 
parameters.

I can declare the equivalent to an invariant function like so:

class C
{
   static f(invariant(C) c) {...}
}

...

auto c = cast(invariant(C)) new C;

// instead of c.f()
C.f(c);

So with your removal of invariant functions, I can still have semantically 
equivalent invariant functions, but it's just more of a pain in the ass to 
use them.  Why do you need to add this difficulty?

-Steve