[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

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



--- Comment #25 from klickverbot <code at klickverbot.at> 2012-06-04 03:07:52 PDT ---
I am partly playing Devil's advocate here, but:

(In reply to comment #23)
> > This is
> > why i suggested above that only dereferencing a pointer should be allowed in
> > pure functions.
> > 
> This is too restrictive.

Why?

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

There is an important semantic difference between these two – a slice is a
bounded region of memory, whereas a pointer per se just represents a reference
to a single value.
---
int foo(int* p) pure {
  return *(p - 1); // Is this legal?
}

auto a = new int[10];
foo(a.ptr + 1);
---

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

In a register, but that's besides the point – which is that the type of i, int,
makes it clear that n depends on exactly four bytes of memory. In »struct Node
{ Node* next; } void foo(Node* n) pure;«, on the other hand, following your
interpretation foo() might depend on an almost arbitrarily large amount of
memory (consider e.g. uninitialized memory in the area between a heap-allocated
Node instance and the end of the block where it resides, which, if interpreted
as Node instance(s), might have »false pointers« to other memory blocks, etc.).

> > > 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 […]

Is it? Could you please repeat the definition then, and point out how this is
clear from the definition of purity according to the spec, »Pure functions are
functions that produce the same result for the same arguments«.

> and f4 must document its valid inputs.
---
/// Passing anything other than `false` is illegal.
int g_state;
void foo(bool neverTrue) pure {
   if (neverTrue) g_state = 42;
}
---

Should this be allowed to be pure? Well, if strlen is, then ostensibly yes, but
isn't this too permissive of an interpretation, as the type system can't
actually guarantee it? Shouldn't rather a cast to pure at the _call site_ be
required if called with know good values, just as in other cases where the type
system can't prove a certain invariant, but the programmer can? Purity by
convention works just fine without the pure keyword as well…

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