On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
>> Agree on it being great and innovative. But I fail to see usefulness with current design. Can you provide examples how current pure design allows for better code / optimizations?
>
> Strongly pure functions can call weakly pure function while keeping its properties.
>
> So it loosen the constraint on strongly pure function while keeping the benefit.

It does not answer my question. Why "pure" keyword is useful in D if it does not guarantee that compiler will verify functional purity of you code and does not guarantee relevant optimizations?

Beauty of concept is useless without practical application.

On Wednesday, 10 April 2013 at 08:19:26 UTC, Dicebot wrote:
> On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
>>> Agree on it being great and innovative. But I fail to see usefulness with current design. Can you provide examples how current pure design allows for better code / optimizations?
>>
>> Strongly pure functions can call weakly pure function while keeping its properties.
>>
>> So it loosen the constraint on strongly pure function while keeping the benefit.
>
> It does not answer my question. Why "pure" keyword is useful in D if it does not guarantee that compiler will verify functional purity of you code and does not guarantee relevant optimizations?
>
> Beauty of concept is useless without practical application.

It isn't beauty of concept. Strongly pure function exhibit from an external point of view the properties of pure as in functional programming.

On Wednesday, 10 April 2013 at 11:22:41 UTC, deadalnix wrote:
> On Wednesday, 10 April 2013 at 08:19:26 UTC, Dicebot wrote:
>> On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
>>>> Agree on it being great and innovative. But I fail to see usefulness with current design. Can you provide examples how current pure design allows for better code / optimizations?
>>>
>>> Strongly pure functions can call weakly pure function while keeping its properties.
>>>
>>> So it loosen the constraint on strongly pure function while keeping the benefit.
>>
>> It does not answer my question. Why "pure" keyword is useful in D if it does not guarantee that compiler will verify functional purity of you code and does not guarantee relevant optimizations?
>>
>> Beauty of concept is useless without practical application.
>
> It isn't beauty of concept. Strongly pure function exhibit from an external point of view the properties of pure as in functional programming.

Except you can't be sure that your function is strongly pure with current design. Add ref parameter into the mix by accident and it will silently change to weak pure which is useless by its own.

On 4/10/13 7:29 AM, Dicebot wrote:
> On Wednesday, 10 April 2013 at 11:22:41 UTC, deadalnix wrote:
>> On Wednesday, 10 April 2013 at 08:19:26 UTC, Dicebot wrote:
>>> On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
>>>>> Agree on it being great and innovative. But I fail to see
>>>>> usefulness with current design. Can you provide examples how
>>>>> current pure design allows for better code / optimizations?
>>>>
>>>> Strongly pure functions can call weakly pure function while keeping
>>>> its properties.
>>>>
>>>> So it loosen the constraint on strongly pure function while keeping
>>>> the benefit.
>>>
>>> It does not answer my question. Why "pure" keyword is useful in D if
>>> it does not guarantee that compiler will verify functional purity of
>>> you code and does not guarantee relevant optimizations?
>>>
>>> Beauty of concept is useless without practical application.
>>
>> It isn't beauty of concept. Strongly pure function exhibit from an
>> external point of view the properties of pure as in functional
>> programming.
>
> Except you can't be sure that your function is strongly pure with
> current design.

I would venture that you are being confused. This seems to indicate insufficient documentation for 'pure'.

Andrei

On Wednesday, 10 April 2013 at 11:29:42 UTC, Dicebot wrote:
> Except you can't be sure that your function is strongly pure with current design. Add ref parameter into the mix by accident and it will silently change to weak pure which is useless by its own.

pure + immutable and value parameters == strongly pure (as in functional). It is really that simple.

On 04/10/2013 05:43 PM, deadalnix wrote:
> On Wednesday, 10 April 2013 at 11:29:42 UTC, Dicebot wrote:
>> Except you can't be sure that your function is strongly pure with
>> current design. Add ref parameter into the mix by accident and it will
>> silently change to weak pure which is useless by its own.
>
> pure + immutable and value parameters == strongly pure (as in
> functional). It is really that simple.

pure notEntirely(){
    return new Object();
}

auto x = notEntirely();
assert(x is x);
assert(notEntirely() !is notEntirely());

On Wednesday, 10 April 2013 at 15:48:43 UTC, Timon Gehr wrote:
> On 04/10/2013 05:43 PM, deadalnix wrote:
>> On Wednesday, 10 April 2013 at 11:29:42 UTC, Dicebot wrote:
>>> Except you can't be sure that your function is strongly pure with
>>> current design. Add ref parameter into the mix by accident and it will
>>> silently change to weak pure which is useless by its own.
>>
>> pure + immutable and value parameters == strongly pure (as in
>> functional). It is really that simple.
>
> pure notEntirely(){
>     return new Object();
> }
>
> auto x = notEntirely();
> assert(x is x);
> assert(notEntirely() !is notEntirely());

Yes, that is the entity vs value I discussed above n that thread. I should have said parameters AND return is a value.

On Wednesday, 10 April 2013 at 15:52:23 UTC, deadalnix wrote:
> ...

And that is exactly what makes it useless. I need one keyword to automatically verify for me that parameters fine, that context is fine, return value is fine etc. This is the basic crucial concept and everything else should be built on top of it, not other way around. No one can say that my function is pure just by seeing keyword because I have probably forgot something. It is like saying that immutable is immutable only if you take care of some cases. Outstanding issue in my opinion.

On 4/9/2013 1:04 AM, Dicebot wrote:
> On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
>> Are you saying the example above is not actually valid code?
>>
>> struct Foo {
>>     int a = 0;
>>     pure int bar( int n ) { // Weakly pure
>>         a += n;
>>         return a;
>>     }
>> }
>>
>> That's not pure. Call it twice with the same args, you'll different
>> answers. How can that possibly be considered pure in any sense?
>> And it's useless in terms of optimisation, so why bother at all? What does
>> it offer?
>
> It is valid code. It is "weak pure". "pure' keyword means both
> "strong pure" or "weak pure" depending on function body. Crap.

No, it is weakly or strongly pure based on the parameter types. bar(int n), for example, has an (implicit) mutable reference to 'this' in its parameter list. To be strongly pure, bar(int n) would have to be declared as:

    const pure int bar(int n);

What the 'pure' keyword says is: "no reads/writes to mutable data from references that do not come through the parameters." Hence, if the parameters are all const or immutable, and it is marked pure, then the function is "strongly pure", meaning "no reads/writes to any externally visible mutable state".

Notably, this is NOT determined by reading the function body, but by examining the parameter types.

The reason for this behavior is so that strongly pure functions can call weakly pure struct/class methods, and yet remain strongly pure. Purity in D would be largely useless otherwise, as very very few functions could be strongly pure.

On 4/9/2013 1:33 AM, Manu wrote:
> How can 'weak pure' reasonably be called any kind of 'pure'? It's not pure at
> all. The function returns a completely different result when called twice.
> That's the definition of not-pure.
> I suggest that no D language newbie would ever reasonably expect that behaviour.

I explained it in another reply here.

I agree that it is initially confusing. I was myself confused about it until Don set me straight!