[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

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



--- Comment #14 from art.08.09 at gmail.com 2012-06-03 13:52:53 PDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Pointers may only access their own memory blocks, therefore exactly those
> > > blocks participate in argument value and return value.
> > 
> > What does 'their own memory block' mean?
> 
> The allocated memory block it points into.

But, as the bounds are unknown to the compiler, it does not have the this
information, it has to assume everything is reachable via the pointer. This is
why i suggested above that only dereferencing a pointer should be allowed in
pure functions.

> > The problem is a pointer is basically an unbounded array,
> 
> That is wrong. The pointer is bounded, but it is generally impossible to devise
> the exact bounds from the pointer alone. This is why D has dynamic arrays.

And one way to make it work is to forbid dereferencing pointers and require fat
ones. Then the bounds would be known. But i don't think anybody would want to
write "f(pointer_to_some_struct[0..1])"...

> > and, if the access isn't restricted somehow, makes the
> > function dependent on global memory state.
> 
> ? A function independent of memory state is useless.

int n(int i) {return i+42;}

> > 
> > > But why does it even matter? Isn't this discussion mostly philosophical?
> > 
> > The compiler will happily assume that template functions are pure even when
> > they clearly are not, and there isn't even a way to mark such functions as
> > "impure" (w/o using hacks like calling dummy functions etc).
> > Example - a function that is designed to operate on arrays, will always be
> > called with a pointer to inside an array, and can assume that the previous and
> > next element is always valid: 
> > 
> >   f4(T)(T* p) {
> >       p[-1] += p[0];
> >    }
> > 
> > The compiler thinks f4() is pure, when it clearly is not; optimizations based
> > on that assumption are likely to result in corrupted data.
> 
> f4 _is_ 'pure' (it does not access non-immutable free variables). The compiler
> is not allowed to perform optimizations that change defined program behavior.

f4 isn't pure, by any definition - it depends on (or in this example modifies)
state, which the caller may not even consider reachable. The compiler can
assume that a pure function does not access any mutable state other than what
can be directly or indirectly reached via the arguments -- that is what
function purity is all about. If the compiler has to assume that a pure
function that takes a pointer argument can read or modify everything, the
"pure" tag becomes worthless. And what's worse, it allows other "truly" pure
function to call our immoral one. 

Hmm, another way out of this could be to require all pointers args in a pure
function to target 'immutable' - but that, again, seems to limiting; "bool f(in
Struct* s)" could not be pure.

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