--- Comment #23 from 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:
------- You are receiving this mail because: -------

Reply via email to