[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

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



--- Comment #23 from timon.gehr at gmx.ch 2012-06-04 02:22:54 PDT ---
(In reply to comment #14)
> (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.

1. It does not need the information. Dereferencing a pointer outside the valid
   bounds results in undefined behavior. Therefore the compiler can just ignore
   the possibility.
2. It can gain some information at the call site. Eg:

int foo(const(int)* y)pure;

void main(){
    int* x = new int;
    int* y = new int;
    auto a = foo(x);
    auto b = foo(y);
    auto c = foo(x);

    assert(a == c);
}

3. Aliasing is the classic optimization killer even without 'pure'.
4. Invalid use of pointers can break every other aspect of the type system.
   Why single out 'pure' ?

> This is
> why i suggested above that only dereferencing a pointer should be allowed in
> pure functions.
> 

This is too restrictive.


> And one way to make it work is to forbid dereferencing pointers and require fat
> ones. Then the bounds would be known.

The bounds are usually known only at runtime.
The compiler does not have more to work with.
>From the compiler's point of view, an array access out of bounds
and an invalid pointer dereference are very similar.

> > > 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;}
> 

Where do you store the parameter 'i' if not in some memory location?


> > 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.

Then it is the caller's fault. What is considered reachable is well-defined,
and f4 must document its valid inputs.

> 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.

No pointer _argument_ necessary.

int foo()pure{
    enum int* everything = cast(int*)...;
    return *everything;
}

As I already pointed out, unsafe language features can be used to subvert the
type system. If pure functions should be restricted to the safe subset, they
can be marked @safe, or compiled with the -safe compiler switch.

> And what's worse, it allows other "truly" pure
> function to call our immoral one. 
> 

Nothing wrong with that.

> 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.

This is why the restriction was dropped.

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