Bug 9230 – Incorrect implicit immutable conversion occurs in pure function

From: http://d.puremagic.com/issues/show_bug.cgi?id=6553 In git head, following code compiles without errors, and asserts in runtime. string foo(in char[] s) pure { return s; // conversion from const(char[]) to string } void main() { char[] buf = ['a']; immutable str = foo(buf); assert(str[0] == 'a'); buf[0] = 'b'; assert(str[0] == 'a'); // fails!? } There is a problem on the return statement in foo. Complier deduces foo to a strong purity function, but its parameter s might refer outer mutable state, so the conversion const(char[]) to string should not be applied. This is an implementation bug of issue 5081. https://github.com/D-Programming-Language/dmd/commit/99e0f21d2a7a19b655d97fa08394a3bc623f10a0 https://github.com/D-Programming-Language/dmd/commit/99e0f21d2a7a19b655d97fa08394a3bc623f10a0#L3R3524 The implicit immutable conversion on return statement is valid only if the strong purity function has *no parameters*. This bug has appeared by the purity calculation improvement by issue 8408.

(In reply to comment #0) > The implicit immutable conversion on return statement is valid only if the > strong purity function has *no parameters*. ...No, this is incorrect. I found a disproof. Correct requirement is: "If all parameters have no mutable indirections, implicit immutable conversion on return statement is allowed." For example: immutable(int[]) foo(int n) { return new int[](n); } immutable(int[]) bar(immutable int[] arr) { return new int[](arr.length); } void main() { immutable a = foo(10); immutable b = bar([1,2]); } Both foo and bar should be allowed.

(In reply to comment #0) > From: http://d.puremagic.com/issues/show_bug.cgi?id=6553 > > In git head, following code compiles without errors, and asserts in runtime. > > string foo(in char[] s) pure { > return s; // conversion from const(char[]) to string > } > void main() { > char[] buf = ['a']; > immutable str = foo(buf); > assert(str[0] == 'a'); > buf[0] = 'b'; > assert(str[0] == 'a'); // fails!? > } > > There is a problem on the return statement in foo. Complier deduces foo to a > strong purity function, but its parameter s might refer outer mutable state, so > the conversion const(char[]) to string should not be applied. > > This is an implementation bug of issue 5081. > > This bug has appeared by the purity calculation improvement by issue 8408. The patch for issue 5081 was corrent, the problem is that the definition of strong purity has been changed since then. (In reply to comment #1) > (In reply to comment #0) > > The implicit immutable conversion on return statement is valid only if the > > strong purity function has *no parameters*. > > ...No, this is incorrect. I found a disproof. > > Correct requirement is: > "If all parameters have no mutable indirections, implicit immutable conversion > on return statement is allowed." > This is the old definition of strong purity.

(In reply to comment #1) > Correct requirement is: > "If all parameters have no mutable indirections, implicit immutable conversion > on return statement is allowed." > Maybe it should say 'no non-immutable indirections'?

(In reply to comment #3) > The patch for issue 5081 was corrent, the problem is that the definition of > strong purity has been changed since then. > This is the old definition of strong purity. Hmm...interesting, and it might be true. I have thought that "the old definition" was a conservative rule, and did proposed issue 8408 to improve it. But, based on your talk, I have *changed* the definition of strong purity more strictly. I withdraw the claim that it was an implementation bug. (In reply to comment #4) > (In reply to comment #1) > > Correct requirement is: > > "If all parameters have no mutable indirections, implicit immutable conversion > > on return statement is allowed." > > Maybe it should say 'no non-immutable indirections'? Yes, it is more exact explanation. (I sometimes called the const qualified indirections to "mutable indirection" - e.g. const(int)[]. Because it is an opposite of "immutable indirection".)

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/afa7a54422dd3ee7d6622e0b83c5c56c238023fb fix Issue 9230 - Incorrect implicit immutable conversion occurs in pure function `hasMutableIndirectionParams()` is based on the old `TypeFunction::purityLevel()` (before fixing issue 8408). So its result is consistent with `TypeFunction::purityLevel() != PUREstrong` in 2.060. Then it *fixes* the regression. https://github.com/D-Programming-Language/dmd/commit/c42d35bcf92cd26c2b83c3d2e5fc21e5a0f2d296 Merge pull request #1418 from 9rnsr/fix9230 Issue 9230 - Incorrect implicit immutable conversion occurs in pure function

Commit pushed to staging at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/260ec594ad14acf72812c2563ab249b71a7c55d2 Merge pull request #1418 from 9rnsr/fix9230 Issue 9230 - Incorrect implicit immutable conversion occurs in pure function

Issue 8998 is related