www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Purity with references and pointers

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
If a pure function takes a reference/pointer, does that state that the result
of 
the function will be the same on two calls to it if the reference/pointer
points 
to the same data in both cases or if the data itself is unchanged?

If it's a matter of pointing to the same data, then that could be horribly 
broken. That would mean that as long as I pased in the same reference, the 
compiler could cache the result but that the actual result of the function
could 
have and should have been different for each call because the object pointed to 
was altered.

- Jonathan M Davis
Sep 18 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:


 If a pure function takes a reference/pointer, does that state that the  
 result of
 the function will be the same on two calls to it if the  
 reference/pointer points
 to the same data in both cases or if the data itself is unchanged?

 If it's a matter of pointing to the same data, then that could be  
 horribly
 broken. That would mean that as long as I pased in the same reference,  
 the
 compiler could cache the result but that the actual result of the  
 function could
 have and should have been different for each call because the object  
 pointed to
 was altered.


"[A] pure function [...] has parameters that are all immutable or are
implicitly convertible to immutable" [1]

This implies that any pointer passed to a pure function must point
to immutable data. This means the pointed-to data can not change
between two calls to the function.


[1]: http://digitalmars.com/d/2.0/function.html#pure-functions
-- 
Simen
Sep 18 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 18 September 2010 17:33:21 Simen kjaeraas wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:

 If a pure function takes a reference/pointer, does that state that the
 result of
 the function will be the same on two calls to it if the
 reference/pointer points
 to the same data in both cases or if the data itself is unchanged?
 
 If it's a matter of pointing to the same data, then that could be
 horribly
 broken. That would mean that as long as I pased in the same reference,
 the
 compiler could cache the result but that the actual result of the
 function could
 have and should have been different for each call because the object
 pointed to
 was altered.


 
 "[A] pure function [...] has parameters that are all immutable or are
 implicitly convertible to immutable" [1]
 
 This implies that any pointer passed to a pure function must point
 to immutable data. This means the pointed-to data can not change
 between two calls to the function.
 
 
 [1]: http://digitalmars.com/d/2.0/function.html#pure-functions


Except that since when is anything implictly convertable to immutable? 
Implicitly converted to const, yes. That happens often enough, but immutable? 
And you definitely don't have to use immutable references with pure functions.

I have gotten some const-related errors when using pure on member functions, so 
I get the impression that using pure on a member function implicitly makes it 
const, but I'm not sure if that's enough. Maybe pure implicitly make all
pointer 
and reference parameters const, and if function purity is only ever used to 
optimize within an expression rather than across multiple statements, then that 
would be enough. But if it tried to optimized multiple pure function calls 
within a function, and there were statements in between which altered one of
the 
objects passed into the pure function, then such an optimization wouldn't 
necessarily be valid.

It sounds to me like the docs need updating. I don't think that *anything* is 
implicitly convertable to immutable. const yes, but not immutable

- Jonathan M Davis
Sep 18 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Jonathan M Davis <jmdavisProg gmx.com> wrote:


 Except that since when is anything implictly convertable to immutable?
 Implicitly converted to const, yes. That happens often enough, but  
 immutable?


Anything that does not contain pointers or references to non-immutable
data is implicitly convertible to immutable, if passed by value.



 And you definitely don't have to use immutable references with pure  
 functions.


That sounds like a bug. Unless you mean things like immutable(char)[],
which is implicitly convertible to immutable, according to the above rules.



 I have gotten some const-related errors when using pure on member  
 functions, so
 I get the impression that using pure on a member function implicitly  
 makes it
 const, but I'm not sure if that's enough.


The 'this' pointer is also a parameter to a function, so also needs to
be immutable.

-- 
Simen
Sep 18 2010
parent Don <nospam nospam.com> writes:
Simen kjaeraas wrote:

 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 

 Except that since when is anything implictly convertable to immutable?
 Implicitly converted to const, yes. That happens often enough, but 
 immutable?


 
 Anything that does not contain pointers or references to non-immutable
 data is implicitly convertible to immutable, if passed by value.
 
 

 And you definitely don't have to use immutable references with pure 
 functions.


 
 That sounds like a bug. Unless you mean things like immutable(char)[],
 which is implicitly convertible to immutable, according to the above rules.
 
 

 I have gotten some const-related errors when using pure on member 
 functions, so
 I get the impression that using pure on a member function implicitly 
 makes it
 const, but I'm not sure if that's enough.


 
 The 'this' pointer is also a parameter to a function, so also needs to
 be immutable.


But that's impossible, except for trivial, useless classes.
Sep 20 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 18 September 2010 18:16:31 Jonathan M Davis wrote:

 I don't think that *anything*
 is implicitly convertable to immutable. const yes, but not immutable


Actually, I guess that value types are implicitly convertible to immutable in 
the sense that you can create a new immutable value from them, but you can't 
convert them in the sense that you use a pointer to them where that pointer is
a 
pointer to immutable. Reference types are never implicitly convertible to 
immutable though. That's why you have to use idup with arrays.

- Jonathan M Davis
Sep 18 2010
prev sibling parent Kagamin <spam here.lot> writes:
Jonathan M Davis Wrote:


 If a pure function takes a reference/pointer, does that state that the result
of 
 the function will be the same on two calls to it if the reference/pointer
points 
 to the same data in both cases or if the data itself is unchanged?
 
 If it's a matter of pointing to the same data, then that could be horribly 
 broken. That would mean that as long as I pased in the same reference, the 
 compiler could cache the result but that the actual result of the function
could 
 have and should have been different for each call because the object pointed
to 
 was altered.


You can search for bug report about purity of stdc string functions. Don
proposed two flavors of purity. When you pass const data to pure function, the
call effectively becomes impure.
Sep 20 2010