After reading Walter's posts these last weeks and Andrei's PDF, I think the D 2.0 invariant/const make a lot of sense, and I can see the how it opens up new possibilities.

I was a bit worried for a performance penalty because of the need for "idup"s, but then I realized that you only .idup when you use "invariant()" when you actually don't care about it being invariant or not. So converting all D 1.0 "char[]" to D 2.0 "string" might not be such a good idea.

One thing that I like is that suddenly C++ "const &" construction can be standardized and made safe at the same time! Because of invariant, "in" can safely pass the arguments by ref, instead of by value.

Sorry for repeating what most probably already know, but it just felt like a revelation that I had to share :-)  A bit slow perhaps, but I'm pretty sure I'm not the last one to /get it/.

Thanks Walter, Andrei for explaining this invariant/const thing over and over again, in different forms.

Now I'll have to change Phobos 2.0 to get "foreach(string s; new BufferedFile(..))" working ;-)

L.

They say the best way to learn is to explain to someone else...

Many have said FP style multithreading requires pure functions with invariant data. The strange thing is that pure functions can't call invariant member functions of their invariant data. Why would that be? That's especially strange when the justification for invariant is multithreading.

I've been arguing for a while that mutable access to globals is like head const and kills most of the benefits from the const system. Please help me understand why I am wrong.

Lionello Lunesu Wrote:

> After reading Walter's posts these last weeks and Andrei's PDF, I think the D 2.0 invariant/const make a lot of sense, and I can see the how it opens up new possibilities.
> 
> I was a bit worried for a performance penalty because of the need for "idup"s, but then I realized that you only .idup when you use "invariant()" when you actually don't care about it being invariant or not. So converting all D 1.0 "char[]" to D 2.0 "string" might not be such a good idea.
> 
> One thing that I like is that suddenly C++ "const &" construction can be standardized and made safe at the same time! Because of invariant, "in" can safely pass the arguments by ref, instead of by value.
> 
> Sorry for repeating what most probably already know, but it just felt like a revelation that I had to share :-)  A bit slow perhaps, but I'm pretty sure I'm not the last one to /get it/.
> 
> Thanks Walter, Andrei for explaining this invariant/const thing over and over again, in different forms.
> 
> Now I'll have to change Phobos 2.0 to get "foreach(string s; new BufferedFile(..))" working ;-)
> 
> L.
> 
> 

On 09/04/2008, Jason House <jason.james.house@gmail.com> wrote:
> The strange thing is that pure functions can't call invariant member functions of their invariant data.

I don't think that's correct.

    class C
    {
        int x;

        int f() invariant pure
        {
            return x;
        }
    }

    invariant c = cast(invariant) new C;
    int n = c.f();

Should work just fine. Of course, the explicit cast necessary to create an invariant C in the first place is a bit ugly. Maybe we need "inew" to make new invariant objects?

Remember, a member function is nothing more nor less than a global function with a hidden parameter and some name mangling. That means that the rules for purity of member functions are identical to those of global functions. You just have to insist that "this" be invariant.

Janice Caron Wrote:

> On 09/04/2008, Jason House <jason.james.house@gmail.com> wrote:
> > The strange thing is that pure functions can't call invariant member functions of their invariant data.
> 
> I don't think that's correct.
> 
> [example showing misinterpretation of what I'm talking about]

Consider this example:

class D{
  void invMemberFunc() invariant; // not pure
}

class C{
  int f(invariant D) invariant pure{
    D.invMemberFunc(); // illegal
  }
}

On 09/04/2008, Jason House <jason.james.house@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?

On Wed, 09 Apr 2008 13:50:59 +0100, Janice Caron wrote:

> On 09/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>> The strange thing is that pure functions can't call invariant member functions of their invariant data.
> 
> I don't think that's correct.
> 
>     class C
>     {
>         int x;
> 
>         int f() invariant pure
>         {
>             return x;
>         }
>     }
> 
>     invariant c = cast(invariant) new C;
>     int n = c.f();
> 
> Should work just fine. Of course, the explicit cast necessary to create an invariant C in the first place is a bit ugly. Maybe we need "inew" to make new invariant objects?
> 

Couldn't the compiler insert the cast based on the declaration?

/* compiler inserts the cast since the declaration is
invariant */
invariant c = new C;

This would also make sense for const.  Is this possible? I think it would be a nice nugget of syntactic sugar.

On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron <caron800@googlemail.com> wrote:

> On 09/04/2008, Jason House <jason.james.house@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

On 09/04/2008, Denton Cockburn <diboss@hotmail.com> wrote:
>  > Of course, the explicit cast necessary to
>  > create an invariant C in the first place is a bit ugly. Maybe we need
>  > "inew" to make new invariant objects?
>
> Couldn't the compiler insert the cast based on the declaration?

No, because objects created by new are not necessarily transitively unique. For example

    class C
    {
        int * p;

        this()
        {
            p = &someGlobalVariable;
        }
    }

    invariant C c = cast(invariant) new C;
    someGlobalVariable = 1;

Whoops! c just changed!

The explicit cast makes it the programmer's fault, not the compiler's!

Come to think of it, "inew" would suffer the exact same problem, so it doesn't solve anything. Looks like there's no easy way to make an invariant class instance.

"Simen Kjaeraas" wrote
> On Wed, 09 Apr 2008 15:40:37 +0200, Janice Caron  wrote:
>
>> On 09/04/2008, Jason House  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.

I think there was a suggestion at one point to change const/invariant functions to be like:

const(this) int f();

instead of

const int f();

Which I think is much clearer.

-Steve

"Janice Caron" wrote
> On 09/04/2008, Denton Cockburn wrote:
>>  > Of course, the explicit cast necessary to
>>  > create an invariant C in the first place is a bit ugly. Maybe we need
>>  > "inew" to make new invariant objects?
>>
>> Couldn't the compiler insert the cast based on the declaration?
>
> No, because objects created by new are not necessarily transitively unique. For example
>
>    class C
>    {
>        int * p;
>
>        this()
>        {
>            p = &someGlobalVariable;
>        }
>    }
>
>    invariant C c = cast(invariant) new C;
>    someGlobalVariable = 1;
>
> Whoops! c just changed!
>
> The explicit cast makes it the programmer's fault, not the compiler's!
>
> Come to think of it, "inew" would suffer the exact same problem, so it doesn't solve anything. Looks like there's no easy way to make an invariant class instance.

Sure there is :)

class C
{
   int *p;
   int q;

   invariant this() // means, 'this' is going to be invariant
   {
       //p = &someGlobalVariable; // fails, p must point to invariant
       q = 5; // allowed by compiler because it's the first time you set q.
       p = &q; // allowed because q is invariant.
   }
}

I think this was outlined in Andrei's presentation about grafting functional languages onto imperitive languages.

Of course, it doesn't work today, but I think it would work.

In fact, I think if you have a class like:

class X{}
class C
{
    invariant X x;
}

There is no way to set x anywhere...  I think this needs to be addressed.

-Steve