2013/4/9 Dicebot <m.strashun@gmail.com>

> On Tuesday, 9 April 2013 at 12:56:04 UTC, Andrei Alexandrescu wrote:
>
>> It is valid code. It is "weak pure". "pure' keyword means both
>>> "strong pure" or "weak pure" depending on function body. Crap.
>>>
>>
>> s/body/signature/
>> s/Crap/Awesome/
>>
>
> Not gonna argue latter but former is just wrong.
>
> struct Test
> {
>     int a;
>     pure int foo1() // strong pure
>     {
>         return 42;
>     }
>
>     pure int foo2() // weak pure
>     {
>         return a++;
>     }
> }
>
> Signature is the same for both functions.
>

Both have weak pure. Purity is always calculated only from the function
signature.
If you make member function "strong pure", _at least_ it should be
qualified with "immutable".

    pure int foo3() immutable // strong pure
    {
        return 10;
    }

Kenji Hara

On Tuesday, 9 April 2013 at 13:49:12 UTC, Dicebot wrote:
> struct Test
> {
>     int a;
>     pure int foo1() // strong pure
>     {
>         return 42;
>     }
>
>     pure int foo2() // weak pure
>     {
>         return a++;
>     }
> }

Isn't it

pure int foo1() const // strong pure

On Tue, 09 Apr 2013 16:09:40 +0200, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:

> On Tuesday, 9 April 2013 at 13:49:12 UTC, Dicebot wrote:
>> struct Test
>> {
>>     int a;
>>     pure int foo1() // strong pure
>>     {
>>         return 42;
>>     }
>>
>>     pure int foo2() // weak pure
>>     {
>>         return a++;
>>     }
>> }
>
> Isn't it
>
> pure int foo1() const // strong pure


const is not sufficient, as someone else might have a mutable
reference. immutable is needed.

-- 
Simen

On Tuesday, 9 April 2013 at 14:06:31 UTC, Pelle Månsson wrote:
> shouldn't be strongly pure (as it can access mutable non local state).

I was under impression that pure is about verifying what function actually does, not what it probably can.

On Tue, 09 Apr 2013 16:15:40 +0200, Dicebot <m.strashun@gmail.com> wrote:

> On Tuesday, 9 April 2013 at 14:06:31 UTC, Pelle Månsson wrote:
>> shouldn't be strongly pure (as it can access mutable non local state).
>
> I was under impression that pure is about verifying what function actually does, not what it probably can.

It's based purely on function signature, so we're dealing with possibles
in many cases.

-- 
Simen

On Tuesday, 9 April 2013 at 14:50:58 UTC, Simen Kjærås wrote:
> On Tue, 09 Apr 2013 16:15:40 +0200, Dicebot <m.strashun@gmail.com> wrote:
>
>> On Tuesday, 9 April 2013 at 14:06:31 UTC, Pelle Månsson wrote:
>>> shouldn't be strongly pure (as it can access mutable non local state).
>>
>> I was under impression that pure is about verifying what function actually does, not what it probably can.
>
> It's based purely on function signature, so we're dealing with possibles
> in many cases.

You got me lost here again. Definition of pure in dlang.org says: "To that end, a pure function:

* does not read or write any global or static mutable state
* cannot call functions that are not pure
* can override an impure function, but an impure function cannot override a pure one
* is covariant with an impure function
* cannot perform I/O"

It is all about behavior, not function signature. And function that takes ref parameter and does not read/write it is pure by this list.

On 4/9/13 9:49 AM, Dicebot wrote:
> On Tuesday, 9 April 2013 at 12:56:04 UTC, Andrei Alexandrescu wrote:
>>> It is valid code. It is "weak pure". "pure' keyword means both
>>> "strong pure" or "weak pure" depending on function body. Crap.
>>
>> s/body/signature/
>> s/Crap/Awesome/
>
> Not gonna argue latter but former is just wrong.
>
> struct Test
> {
> int a;
> pure int foo1() // strong pure
> {
> return 42;
> }
>
> pure int foo2() // weak pure
> {
> return a++;
> }
> }
>
> Signature is the same for both functions.

Both are weakly pure.

Andrei

On Tuesday, 9 April 2013 at 15:20:48 UTC, Andrei Alexandrescu wrote:
>> Not gonna argue latter but former is just wrong.
>>
>> struct Test
>> {
>> int a;
>> pure int foo1() // strong pure
>> {
>> return 42;
>> }
>>
>> pure int foo2() // weak pure
>> {
>> return a++;
>> }
>> }
>>
>> Signature is the same for both functions.
>
> Both are weakly pure.
>
> Andrei

And that is even more surprising as foo2 perfectly matches concept of pure and can be applied all possible optimizations to. It is weird. "weak pure" is useful only to implement "strong pure". "strong pure" is useful only if it can be statically enforced to provide some guarantees. "strong pure" is useless because it shares same annotation with "weak pure".

On Tuesday, 9 April 2013 at 15:42:38 UTC, Dicebot wrote:
> On Tuesday, 9 April 2013 at 15:20:48 UTC, Andrei Alexandrescu wrote:
>>> Not gonna argue latter but former is just wrong.
>>>
>>> struct Test
>>> {
>>> int a;
>>> pure int foo1() // strong pure
>>> {
>>> return 42;
>>> }
>>>
>>> pure int foo2() // weak pure
>>> {
>>> return a++;
>>> }
>>> }
>>>
>>> Signature is the same for both functions.
>>
>> Both are weakly pure.
>>
>> Andrei
>
> And that is even more surprising as foo2 perfectly matches concept of pure

Don't you mean foo1? I have no idea what i'm talking about but foo1 looks a lot more pure than foo2 to me.

On Tuesday, 9 April 2013 at 15:52:36 UTC, John Colvin wrote:
> Don't you mean foo1? I have no idea what i'm talking about but foo1 looks a lot more pure than foo2 to me.

foo1, of course, beg my pardon.