http://d.puremagic.com/issues/show_bug.cgi?id=8185
--- Comment #23 from timon.g...@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: -------