http://d.puremagic.com/issues/show_bug.cgi?id=8185
klickverbot <c...@klickverbot.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal --- Comment #4 from klickverbot <c...@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: -------