[Issue 2732] Setting new key for Associative Array of Static Array causes RangeError

2019-07-13 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=2732

Mathias LANG  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pro.mathias.l...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Mathias LANG  ---
Closing as D1 is retired.

--


[Issue 2732] Setting new key for Associative Array of Static Array causes RangeError

2011-06-10 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2732


yebblies yebbl...@gmail.com changed:

   What|Removed |Added

 CC||yebbl...@gmail.com
Version|2.025   |D1


--- Comment #3 from yebblies yebbl...@gmail.com 2011-06-10 08:35:44 PDT ---
This works in D2.053, but still throws a RangeError in D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 2732] Setting new key for Associative Array of Static Array causes RangeError

2009-03-30 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2732





--- Comment #2 from hs...@inter7.jp  2009-03-30 06:02 ---
(In reply to comment #1)

real[2][int] hash = null;
real[2] v = [3,4];

*(hash[0])=1;
write(hash[0]);
// - [1 0], very strange result. where does 0 come from? *1

hash[0]=v;
write(hash[0]);
// - [3 4], it works well if key have been already set.


*1
real.init is NaN. actually: write(new real[2]) - [nan nan].
This test code might show us a different bug of accepts-invalid.

To make matters worse, following code is compiled without any error
and cause runtime object.Exception: lengths don't match for array copy.

real[1] v = [3,4];

I think that this code should be an compile-time error because
the compiler knows types of both `real[1] v' and `[3,4]'.
I will report these bugs if they have not been reported on this tracking
system.


--