On Tue, 25 Mar 2014 14:49:27 -0400, Artur Skawina <[email protected]>
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
