Forcing weak-pure

[Artur Skawina]

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]);

artur