[Issue 8185] Pure functions and pointers

[d-bugmail at puremagic.com]

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


klickverbot <code at klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal


--- Comment #4 from klickverbot <code at klickverbot.at> 2012-06-02 07:50:05 PDT ---
(In reply to comment #3)
> And my original question is
> > The Question: What exactly does these pure functions consider as `argument
> value` and as `returned value`?
> 
> Illustration:
> ---
> int f(in int* p) pure;

Thanks for the example, this certainly makes your concerns easier to see. You
are right, the spec is really not clear in this regard – but in my opinion,
only a single interpretation makes sense, in that it is actually enforceable by
the compiler:

---
>     auto res = f(arr.ptr);
>     assert(res == f(arr.ptr));
This one obviously has to pass.

>     assert(res == f(arr.ptr + 1)); // *p isn't changed
Might fail, f is allowed to return cast(int)p.

>     arr[1] = 7;
>     assert(res == f(arr.ptr)); // neither p nor *p is changed
Must pass, reading/modifying random bits of memory inside pure functions is
obviously a bad idea. Bad idea meaning that pointer arithmetic is disallowed in
@safe code anyway, and in @system code, you as the programmer are responsible
for not violating the type system guarantees – for example, you can just call
any impure function in a pure context using a cast. This also means that e.g. C
string functions cannot not be pure in D.

>     arr[0] = 7;
>     assert(res == f(arr.ptr)); // p isn't changed
Might fail, as discussed in the »What about Referential Transparency« section
of the article – only if the parameters are _transitively_ equal (as defined by
their type), then pure functions are guaranteed to return the same value.

> The second assert is here according to
> http://klickverbot.at/blog/2012/05/purity-in-d/.
Then this aspect of the article is apparently not as clear as it could be –
thanks for the feedback, I'll incorporate it in the next revision.
---

Do you disagree with any of these points? If so, I'd be happy to provide a more
in-depth explanation of my view, so we can clarify the spec afterwards.

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