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: nob...@puremagic.com
ReportedBy: verylonglogin....@gmail.com
--- Comment #0 from Denis Shelomovskij <verylonglogin....@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: -------
