On Tuesday, 9 April 2013 at 08:33:53 UTC, 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.

It is "weak pure" because it can be called by "strong pure" functions without violating "strong pure" guarantees (not-pure-at-all functions can't). It is confusing indeed and I remember some questions on StackOverflow on topic. I think having separate keywords/attributes would have helped.

On Tue, 09 Apr 2013 10:33:45 +0200, Manu <turkeyman@gmail.com> wrote:

> On 9 April 2013 18:04, Dicebot <m.strashun@gmail.com> 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.
>>
>
> How can 'weak pure' reasonably be called any kind of 'pure'?

It's pure in the sense that it can be used inside (strongly) pure functions.


> I suggest that no D language newbie would ever reasonably expect that
> behaviour.

And with that, I absolutely have to agree.

-- 
Simen

On 04/09/2013 09:56 AM, Dicebot wrote:
> You can't and this is the most stupid thing about pure in D. Compiler can detect which one it is, but you can't force it to accept "pure" only as "strong pure".

This is surely not so terrible -- it leaves the door open for a new keyword (strong pure actually seems quite good) which _does_ enforce that the function is strongly pure.

On 04/08/2013 08:14 PM, Simen Kjaeraas wrote:
> Like others have stated, it's so you can do this:
> 
> struct Foo {
>    int a = 0;
>    pure int bar( int n ) { // Weakly pure
>        a += n;
>        return a;
>    }
> }
> 
> pure int Baz( int n ) { // Strongly pure
>     Foo foo;
>     return foo.bar( n );
> }

... one clear application of this being pseudo-random number generation, where you have a state variable together with a (pure) update function.

On 04/09/2013 05:30 AM, Walter Bright wrote:
> On 4/8/2013 5:39 AM, Manu wrote:
>> But D makes no further guarantee. I don't see how const in D is any
>> different
>> than const in C++ in that sense? That's basically the concept of
>> const, it's not
>> a useful concept for optimisation, only immutable is.
>
> In C++, it is legal to cast away const and mutate it. That is undefined
> behavior in D.
>
> A D compiler can assume, for example, that a const reference passed to a
> pure function will not mutate that reference, nor anything transitively
> referred to by that reference. No such assumption can be made like that
> in C++.

The back end can assume this only if the DMD front end does its homework. It doesn't, probably because the spec does not formalize the type checking rules. There are plenty cases where a pure function can mutate something transitively referenced by some argument in @safe code, even if all arguments are qualified const.

eg. http://d.puremagic.com/issues/show_bug.cgi?id=9149

On 04/09/13 02:44, deadalnix wrote:
> On Monday, 8 April 2013 at 15:07:31 UTC, Jacob Carlborg wrote:
>> I though that wasn't possible. What's the point of pure if that's possible?
> 
> You have to think that this is an hidden parameter. The function touch that parameter, no global state.

D's pure is horribly misnamed; nobody that's not already aware of the D re-definition expects "pure" to mean what it currently does.

   struct S {
      int* p;
      int f() pure @safe nothrow { return ++*p; }
   }

   int i = 1;

   int main() {
      auto s = S(&i);
      assert(i==1);
      auto r = s.f();
      assert(r==2);
      r = s.f();
      assert(r==3);
      assert(i==3);
      return r;
   }

That's not pure by any definition, and fixing it w/o impacting valid cases would be non-trivial (think array members).

artur

On 04/09/2013 10: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.

(Actually this is not the definition of impure.)

In D, 'pure' forbids reading or writing of mutable static variables.

> I suggest that no D language newbie would ever reasonably expect that
> behaviour.

Sure. Many keyword choices in D are unhelpful for newbies, or technically wrong.

enum   -> const
catch  -> handle
do     -> repeat
for    -> (no suggestion)
const  -> readonly
inout  -> (no suggestion)
lazy   -> byname
pure   -> (no suggestion)
static -> (no suggestion)
struct -> (no suggestion)
throw  -> raise / signal
union  -> (no suggestion)

On 9 April 2013 19:43, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net
> wrote:

> On 04/08/2013 08:14 PM, Simen Kjaeraas wrote:
> > Like others have stated, it's so you can do this:
> >
> > struct Foo {
> >    int a = 0;
> >    pure int bar( int n ) { // Weakly pure
> >        a += n;
> >        return a;
> >    }
> > }
> >
> > pure int Baz( int n ) { // Strongly pure
> >     Foo foo;
> >     return foo.bar( n );
> > }
>
> ... one clear application of this being pseudo-random number generation,
> where
> you have a state variable together with a (pure) update function.
>

There's nothing 'pure' about a function that has side effects. It's a totally different concept, and should be named appropriately.

On 04/09/2013 12:13 PM, Artur Skawina wrote:
> ...
> D's pure is horribly misnamed; nobody that's not already aware of the
> D re-definition expects "pure" to mean what it currently does.
>
>     struct S {
>        int* p;
>        int f() pure @safe nothrow { return ++*p; }
>     }
>
>     int i = 1;
>
>     int main() {
>        auto s = S(&i);
>        assert(i==1);
>        auto r = s.f();
>        assert(r==2);
>        r = s.f();
>        assert(r==3);
>        assert(i==3);
>        return r;
>     }
>
> That's not pure by any definition,

I'd counter that it is pure by the D definition.

On Tuesday, 9 April 2013 at 10:28:16 UTC, Manu wrote:
> There's nothing 'pure' about a function that has side effects. It's a
> totally different concept, and should be named appropriately.

It's not totally different – the possible side effects are still very localized and controllable by the *caller* (not the callee). But yes, the name is a bit unfortunate, and has historical reasons.

As to not repeat myself, I'll just link to an article I wrote a couple of months ago: http://klickverbot.at/blog/2012/05/purity-in-d/#weak_purity_allows_for_stronger_guarantees

David