Do pure functions solve the "return const" problems?

[Christopher Wright]

Janice Caron wrote:
> The compiler is fully entitled to reorder
> 
>     a = 5;
>     b = 9;
> 
> into
> 
>     b = 9;
>     a = 5;
> 
> if it so chooses. On a multi-core architecture, these assignments
> might even happen simultaneously.

In that case, passing in the same variable as multiple out parameters 
results undefined behavior currently. And that means that multiple 
return values is exactly equivalent to out parameters. (Or if "a, a = 
someFuncWithMultipleReturnValues();" is well defined, then out 
parameters can at least be converted to multiple return values.)

>> It'd take more effort to prevent out parameters for pure functions.
> 
> That's clearly not true. Rule one is that a pure function "has
> parameters that are all invariant or are implicitly convertible to
> invariant". (See
> http://www.digitalmars.com/d/2.0/function.html#pure-functions ). Out
> parameters fail immediately on account of not being invariant.

Argh, where is my mind today. Or yesterday, rather.

You'd have to change something like:
if (arg->storageClass & STCinvariant)

to:
if (arg->storageClass & (STCinvariant | STCout))

And then you'd have to amend the spec to mention the exception.