Need help with druntime PR 2838 (fix for issue 11725: aa.dup should return mutable copy)

Simen Kjærås simen.kjaras at
Fri Oct 25 11:05:15 UTC 2019

On Thursday, 24 October 2019 at 19:11:29 UTC, H. S. Teoh wrote:
> Basically, the problem is that the new version of AA.dup 
> returns a mutable copy of an AA, but the compiler is not 
> inferring uniqueness for the return value so dup'ing an 
> immutable AA (like int[int]) cannot implicitly convert back to 
> the original type.
> I looked at .dup for arrays in object.d, and apparently there's 
> some kind of trick involving DIP25 that allows the compiler to 
> infer uniqueness (thereby implicit convertibility to the 
> original type), but I don't understand how it works or 
> how/whether it can be applied to the AA case.
> Any ideas?

Pretty sure this is on DMD, and not something you can work around 
in a library. This reduced example shows the problem:

unittest {
     import std.traits : Parameters;
     Parameters!fun a;
     immutable b = fun(a);

pure int[int] fun(int[int] funarg) {
     int[int] aa;
     return aa;

It fails to compile for the exact same reason.

Interestingly, fun([1:1]) *does* implicitly convert to immutable, 
and if you change funarg in any way to differ from 
ReturnType!fun, it seems to compile. I'd chalk it up to 
overzealous purity checks.


More information about the Digitalmars-d mailing list