If the argument values that given to a function marked as pure doesn't appear in its return value, then the function should become 'strong purity'.
An example:
int[] func(const(int)[] arr) pure;
The parameter 'arr' refers const integers through its slice, but func returns int[], so func cannot return arr directly (without unsafe cast) and becomes 'strong purity' function.
The parameter 'arr' refers const integers through its slice, but func returns int[]. const(int)[] is not implicitly convertible to int[], then func cannot return arr directly (without unsafe cast like cast(int[]) arr) and becomes 'strong purity' function.
Comment #2 by bearophile_hugs — 2012-09-09T07:03:15Z
This rule makes more functions (tagged as pure) become strongly pure, this is positive.
On the other hand for the programmer it's increasingly harder to know if a function is weak pure or strongly pure just looking at it.
Comment #3 by k.hara.pg — 2012-09-09T07:24:46Z
(In reply to comment #2)
> This rule makes more functions (tagged as pure) become strongly pure, this is
> positive.
Thanks. But, I've been filed this as a part of issue 8409, so the pull request doesn't cover all cases.
> On the other hand for the programmer it's increasingly harder to know if a
> function is weak pure or strongly pure just looking at it.
I think it is not so difficult if you summarize it.
- If the function can modify function argument through its parameters, it is weakly pure.
- If the function arguments don't appear in the part of the returned value, or the returned value is not a part of arguments, then it is strongly pure.
- Otherwise, it is constant pure.
Comment #4 by bearophile_hugs — 2012-11-12T20:23:55Z
*** Issue 9011 has been marked as a duplicate of this issue. ***
Comment #5 by github-bugzilla — 2012-12-03T22:00:20Z
Comment #6 by bearophile_hugs — 2012-12-05T17:36:09Z
Is it correct that x1 refused and x2 accepted?
char[] foo1(int[] arr) pure {
return new char[10];
}
immutable(char)[] foo2(int[] arr) pure {
return new char[10];
}
void main(string[] args) {
immutable x1 = foo1([1, 2]); // Error: cannot implicitly convert
immutable x2 = foo2([1, 2]); // OK
}
Comment #7 by bearophile_hugs — 2012-12-06T18:07:32Z
(In reply to comment #6)
> Is it correct that x1 refused and x2 accepted?
I guess I have to wait or Issue 8409 to be fixed before looking for possible troubles.
Comment #8 by k.hara.pg — 2012-12-06T19:33:50Z
(In reply to comment #6)
> Is it correct that x1 refused and x2 accepted?
>
>
> char[] foo1(int[] arr) pure {
> return new char[10];
> }
> immutable(char)[] foo2(int[] arr) pure {
> return new char[10];
> }
> void main(string[] args) {
> immutable x1 = foo1([1, 2]); // Error: cannot implicitly convert
> immutable x2 = foo2([1, 2]); // OK
> }
I'm not sure that this should be allowed.
foo1 can rewrite the elements referred from arr, then it is deduced to weak purity. In current principle, the returned value from weak purity function cannot be converted to immutable implicitly (it is only allowed for strong purity function).
If you change the signature of foo1 to:
char[] foo1(const int[] arr) pure;
Then foo1 will be deduced to strong purity, and implicit conversion to immutable for initializing x1 will be succeeded.
Comment #9 by bearophile_hugs — 2012-12-10T18:31:16Z
(In reply to comment #8)
> I'm not sure that this should be allowed.
> foo1 can rewrite the elements referred from arr, then it is deduced to weak
> purity. In current principle, the returned value from weak purity function
> cannot be converted to immutable implicitly (it is only allowed for strong
> purity function).
>
> If you change the signature of foo1 to:
>
> char[] foo1(const int[] arr) pure;
>
> Then foo1 will be deduced to strong purity, and implicit conversion to
> immutable for initializing x1 will be succeeded.
You are right, thank you for your answer.
(If you want me/us to try to suggest improvements in how you write in English, I am willing to help you, despite I am not a good English teacher.)
Comment #10 by timon.gehr — 2012-12-10T18:37:41Z
(In reply to comment #8)
> (In reply to comment #6)
> > Is it correct that x1 refused and x2 accepted?
> >
> >
> > char[] foo1(int[] arr) pure {
> > return new char[10];
> > }
> > immutable(char)[] foo2(int[] arr) pure {
> > return new char[10];
> > }
> > void main(string[] args) {
> > immutable x1 = foo1([1, 2]); // Error: cannot implicitly convert
> > immutable x2 = foo2([1, 2]); // OK
> > }
>
> I'm not sure that this should be allowed.
> ...
Why not? It is known at the call site that anything foo1 will return is newly allocated. Strong or weak purity is irrelevant.
Comment #11 by k.hara.pg — 2012-12-10T19:39:00Z
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #6)
> > I'm not sure that this should be allowed.
> > ...
>
> Why not? It is known at the call site that anything foo1 will return is newly
> allocated. Strong or weak purity is irrelevant.
Your argument had be true.
I had re-read issue 5081, and could be believed that between the purity level (strong, constant, weak) and the conversion possibility to immutable of returned value are irrelevant.
From: http://d.puremagic.com/issues/show_bug.cgi?id=5081#c2
> Note actually that as long as you can verify the return value did not come
> directly from the parameters, it's also possible to implicitly cast to
> immutable.
>
> For example:
>
> pure T[] mydup(T)(const(T)[] param) {...}
>
> It's provable that the return value did not come from param (without a cast),
> because you can't implicitly cast param to T[]. So you can cast the result to
> immutable, >>>>even if param began as mutable<<<<.
The last sentence describes the ideal behavior.
Thanks a lot!
Comment #12 by yebblies — 2013-01-16T06:07:31Z
*** Issue 6783 has been marked as a duplicate of this issue. ***
Comment #13 by yebblies — 2013-01-16T06:14:02Z
Is issue 8998 a regression caused by this patch?
Comment #14 by github-bugzilla — 2013-03-03T16:07:38Z