www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need help with druntime PR 2838 (fix for issue 11725: aa.dup should

reply "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

-- 
Век живи - век учись. А дураком помрёшь.
Oct 24
parent 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
Oct 25