Do pure functions solve the "return const" problems?

[Christopher Wright]

Janice Caron wrote:
> That's irrelevant. globalVariable is assigned /after/ the function
> returned (not during function execution, as would be the case with an
> out parameter).

The compiler is free to change that, should change that, and has the 
necessary information to change that. Since a function isn't allowed to 
read its out parameters, the assignments can be delayed until the 
function exits.

The point is, it isn't going to be terribly difficult to implement out 
parameters in pure functions, it will make them prettier in some cases, 
and there isn't any strong reason to disallow them. You can pull out 
maybe two or three more weak reasons, but it'd be reasonably simple to 
work around them.

Of course, since out parameters are syntactic sugar for multiple return 
values, you might say it's not worthwhile to implement this because it'd 
be too difficult for the benefit. That's an acceptable argument.

> Assigning a global variable *during function execution* violates the
> contract for purity, but you can do whatever you like with return
> values, after the function exits.
> 
> 
>>> Out parameters must
>>> be forbidden, or those assumptions fail.
>>  Then so must return values!
> 
> Watch closely. Given
> 
>     int f(out int x, int y) { x = y+2; return y-1; }
>     int g(out int x, int y) { x = y-1; return y+1; }

Why are you still using this example? It's undefined behavior WITHOUT 
pure; OF COURSE it's undefined behavior with pure!