[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

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



--- Comment #16 from art.08.09 at gmail.com 2012-06-03 15:50:29 PDT ---
(In reply to comment #15)
> pure by itself indicates a weakly pure function. That function enables _zero_

Inventing terminology doesn't help, especially when the result is so confusing.


> optimizations. It is _not_ pure in the sense that the functional or
> mathematical community would consider pure. It is not even _trying_ to be pure
> in that sense. What weak purity does is enable _strong_ purity to actually be
> useful.
> 
> When the compiler can guarantee that all of a pure function's arguments
> _cannot_ be altered by that function, _then_ it is strongly pure. Currently,
> that gurantee is in effect only when all of the parameters of the function are
> immutable or implicitly convertible to immutable. It could be extended to const
> parameters in the case when they're passed immutable arguments, but that isn't
> currently done.
[...]

tl;dr.

The bugtracker is probably not the right place for this discussion; we could
move it to the ML, but talking about it only makes sense if D can be fixed;
otherwise we would be wasting our time...

Limiting "pure" to just immutable data would work indeed, but it's much too
limiting.

   struct S {int a,b; int[64] c; bool f() const pure {return a||b;}}

   int g(S* p) {
      int r;
      foreach (i; 0..64)
         if (p.f())
            r |= p.c[i];
      return r;
   }


Using your "weak pure" definition, f's "pure" would be a NOOP - that is not
what most people would expect, and is not a sane purity implementation. 
It's not a problem for trivial examples such as this one because inlining
should take care of it, but would make "pure" almost useless in real code, as
it would almost never be, to use your terminology again, "strongly" pure (and
couldn't be moved out of the loop).

Note that, even when using your "strong purity" definition, the compiler still
does the wrong thing - some of the examples I gave previously in this bug are
(and others can be trivially modified to be) inferred as "strongly" pure
functions, when they are not pure at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------