https://github.com/dlang/druntime/pull/2838

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?


T

-- 
Век живи - век учись. А дураком помрёшь.

On Thursday, 24 October 2019 at 19:11:29 UTC, H. S. Teoh wrote:
> https://github.com/dlang/druntime/pull/2838
>
> 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.

--
  Simen