Forcing weak-pure

[Steven Schveighoffer]

On Tue, 25 Mar 2014 14:49:27 -0400, Artur Skawina <art.08.09 at gmail.com>  
wrote:

> On 03/25/14 14:30, Steven Schveighoffer wrote:
>> [...] functions like GC.setAttr and assumeSafeAppend cannot be marked  
>> pure. For example:
>>
>> auto str = "hello".idup;
>> str = str[0..1];
>> str.assumeSafeAppend();
>> str ~= "iya";
>>
>> The compiler could rationally elide the call to assumeSafeAppend if it  
>> is pure. We are not using the return value, and the only parameter is  
>> immutable. Since pure functions technically have no side effects, this  
>> call can be eliminated. A recent compiler change made such calls  
>> warnings (not using result of strong-pure function). But  
>> assumeSafeAppend really should be weak-pure, because it does have an  
>> effect. In essence, you are technically passing to assumeSafeAppend a  
>> pointer to the block that contains the slice, not the slice itself. And  
>> that block is mutable.
>>
>> GC.setAttr has similar issues.
>>
>> How can we force these to be weak-pure?
>
> Functions returning 'void' and w/o mutable args cannot be logically pure,
> as long as they aren't no-ops, obviously. While this property could be
> used to render them "weak-pure" in d-speak, this (or any other approach
> to marking them as such) would not be enough...
>
>    // assuming 'assumeSafeAppend()' is "weak-pure":
>
>    string f(string s) pure { s.assumeSafeAppend(); s ~= "d"; return s; }
>   string a = "abc".idup, b = f(a[0..2]);

This could not be elided, because you are using the return value. It would  
have to be called at least once.

However, I am OK with it being elided for a second call with the same  
input. In other words, this strong pure function does not have the same  
issues.

But I get what you are saying -- just wrap it again, and we're back to the  
same issue. It is a systematic problem, because the concept is that you  
are not passing mutable references, even though you are then using those  
references to mark global data.

There is no really good answer I suppose. The huge downside of not marking  
assumeSafeAppend as weak-pure is that one cannot use assumeSafeAppend or  
set attributes inside pure functions that deal with arrays with immutable  
data. For example, the Appender type cannot be marked pure for immutable  
data.

-Steve