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
