• H. S. Teoh (14/14) Oct 24 2019 https://github.com/dlang/druntime/pull/2838
• Simen =?UTF-8?B?S2rDpnLDpXM=?= (19/31) Oct 25 2019 Pretty sure this is on DMD, and not something you can work around

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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

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

Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:

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