[REG2.051] Issue 12420 - [AA] Can't set associative array with array as key value using key type #3408
Conversation
| Type *t2b = e2->type->toBasetype(); | ||
| if (t2b->ty == Tarray && t2b->nextOf()->isMutable()) | ||
| if (t2b->ty == Tarray && !e2->implicitConvTo(taa->index->immutableOf())) |
|
I expect we're going to see a lot more like the phobos breakage in real-world code. I'm not sure requiring AA keys to be immutable was a good idea. Also, could you track down that stray |
|
Please, no. See my Issue 12420 Comment 3. Let's just fix Issue 2954 which will auto-fix Issue 12420 and leave enhancement 12491 for future discussion. Considering code-breakage it will cause I don't expect it will be accepted. Looks like it's too late for D associative arrays to become correct. |
|
Hey, you ask, you get. Don't get cold feet now it's happening. The 'immutable' in the error message didn't match the check, but it certainly matched the intent. |
Sorry for being unclear. But now enhancement 12491 is filed and open for discussion.
I don't like reading one's mind without his will. |
No, I finally con't agree at all with this statement. I proposed to "remove the hack" in the original issue. I can't see how it can be treated as an indention to leave and even make the hack more strong as it's just totally inconsistent to select arrays from all types with indirections and check only it for immutability. |
|
This is removing the hack, and partially implementing the enhancement. |
For me "hack" is inconsistent selection of arrays from all types with indirections. |
…value using key type And add test case for issue 2954.
|
OK, I misunderstood the described issue in 12420. In D, all AA keys must not be mutable. Therefore, accepting |
|
Note that, this change itself is still valid independently from the issue 12420. But it will break some existing code. So I close this PR. |
https://d.puremagic.com/issues/show_bug.cgi?id=12420
And add test case for issue 2954.