On Mon, 19 May 2014 09:42:31 -0400 Steven Schveighoffer via Digitalmars-d <[email protected]> wrote:
> On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d > <[email protected]> wrote: > > > On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via > > Digitalmars-d wrote: > >> On Thu, 15 May 2014 08:43:11 -0700 > >> Andrei Alexandrescu via Digitalmars-d <[email protected]> > >> wrote: > >> > >> > On 5/15/14, 6:28 AM, Dicebot wrote: > >> > > This is not true. Because of such code you can't ever > >> > > automatically memoize strongly pure function results by > >> > > compiler. A very practical concern. > >> > > >> > I think code that doesn't return pointers should be memoizable. > >> > Playing tricks with pointer comparisons would be appropriately > >> > penalized. -- Andrei > >> > >> Agreed. The fact that a pure function can return newly allocated > >> memory pretty much kills the idea of being able to memoize pure > >> functions that return pointers or references, because the program's > >> behavior would change if it were to memoize the result and reuse > >> it. > > Memoizing reference returns that are immutable should be fine. Only if you consider it okay for the behavior of the function to change upon memoization - or at least don't consider that the behaviors changed due to the fact that the objects are equal but not the same object (which can matter for reference types) is something that matters. It has less of an impact when you're dealing with immutable objects, because changing the value of one won't change the value of another, but it can still change the behavior of the program due to the fact that they're not actually the same object. So, I'd be inclined to argue that no functions which return memory should be memoizable. And given that the compiler can only memoize functions within a single expression (or maybe statement - I can't remember which) - I don't think that that restriction even costs us much. - Jonathan M Davis
