Comment: Allowing this would mean that nested pure functions would no longer be able to use the parameters from the enclosing function.

pure int fun(int d, int divisor)
{
   int gun() pure { return d+1; } // would be illegal, since 'fun' could modify d.
    return gun() + d / divisor;
}

Which in turn would mean that nested pure functions would become quite useless. So there's a price to pay.

Instead of introducing another inconsistency into the language for the not-so-common case, you could take the opposite route:

pure int fun(int d, int divisor)
{
   immutable c = d;
   int gun() pure { return c + 1; }

   return gun() + d / divisor;
}

(In reply to comment #2)
> Instead of introducing another inconsistency into the language for the
> not-so-common case, you could take the opposite route:
> 
> pure int fun(int d, int divisor)
> {
>    immutable c = d;
>    int gun() pure { return c + 1; }
> 
>    return gun() + d / divisor;
> }

I think the existing behaviour -- that you cannot change any of the parameters in a pure function -- is simple and intuitive: pure functions can only modify variables which they created themselves. A rule that pure nested functions can use indirectly-referenced data, but cannot use parameters which are passed by value, just seems complicated. 
Especially, in the case where a parameter contains a reference to other data, it seems folly to be allowed to change part of the parameter, but not all of it.

> I think the existing behaviour -- that you cannot change any of the parameters
> in a pure function -- is simple and intuitive: pure functions can only modify
> variables which they created themselves.

But the passed-by-value parts of the arguments are copied and consequently can be qualified as "variables which they created themselves".

> A rule that pure nested functions can
> use indirectly-referenced data, but cannot use parameters which are passed by
> value, just seems complicated.

I don't think it is too complicated. It can be trivially done like this:

pure int foo(in int d, ...)
{
 // now we should be able to use d in pure nested functions because it is 
 // guaranteed to not change during the function call.
}

> Especially, in the case where a parameter contains a reference to other data,
> it seems folly to be allowed to change part of the parameter, but not all of
> it.

I am not sure. For example, it seems to be fairly intuitive to be able to rebind a string parameter, though changing the referenced part of it is not allowed. I would agree if D's function parameters behaved like aliases to the arguments, but they are more like the function's local variables, which arguments are assigned to.

Now that I am trying to purify some functions (most of which have no nested functions) I need to add the useless temporaries to make them compile :(

This would reintroduce "tail-const" for the parameters, something that we tried hard to make work and failed. I'd rather just leave the parameters const. If you have to make a mutable copy, as in:

  pure int fun(int d, int divisor)
  { auto x = d;
    if (x < 0)
        x -= divisor - 1;
    return x / divisor;
  }

that isn't much of a burden, and the compiler will optimize the extra copy away anyway.

*** Issue 4630 has been marked as a duplicate of this issue. ***

Note that (with dmd 2.049)

pure int f(int i)
{
  return ++i;
}

doesn't compile, yet

pure auto f(int i)
{
  return ++i;
}

does work (int return type is replaced with auto).

Also http://www.digitalmars.com/d/2.0/function.html section "Pure Functions" gives an example of assignment to parameter,

  i = y;    // ok, reading immutable global state

Created separate issue http://d.puremagic.com/issues/show_bug.cgi?id=4915 for "int -> auto", as auto return type escapes pure completely.

In the recent update of relaxed purity, this code now compiles. However I believe this is a weakly pure function as a strongly pure function requires its parameters to be immutable.