[Issue 8185] New: Pure functions and pointers

[d-bugmail at puremagic.com]

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

           Summary: Pure functions and pointers
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: verylonglogin.reg at gmail.com


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg at gmail.com> 2012-06-02 12:10:50 MSD ---
Look's like there is a big problem with pure functions and pointers.

Consider these functions:
---
int*   f1(in int*   i) pure;
int**  f2(in int**  i) pure;
void*  g1(in void*  p) pure;
void** g2(in void** p) pure;

struct MyArray { int* p; size_t len; }
void** h(in MyArray arg) pure;
---
The Question: What exactly does these pure functions consider as `argument
value` and as `returned value`? Looks like this is neither documented nor
obvious.

I see the only two ways to document it properly (yes, the main problem is with
`h` function):
 * disallow pure functions to accept pointers or types with pointers;
 * once pure function accepts a pointer it is considered depending on all
process memory;
 * state with BIG RED LETTERS that pure function depends on the address only
and restrict dereferencing of the pointer on a compiler level.

The second way obviously just means the function isn't pure any more.
The third way means the pointer isn't a pointer any more so I'd prefer to
replace is with "The first way" + "f(cast(size_t) ptr)".

More than that, the situation is very dangerous now. E.g. one can consider
`strlen` to be pure. It should be clearly stated that purity is compiler
checkable, not user checkable with examples like `strlen`. See discussion in
Issue 3057.

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