Bug 5199 – null implicitly converts to any other type on array assignment
Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
Windows
Creation time
2010-11-10T12:06:00Z
Last change time
2010-11-16T21:39:09Z
Keywords
accepts-invalid, diagnostic
Assigned to
nobody
Creator
dsimcha
Comments
Comment #0 by dsimcha — 2010-11-10T12:06:42Z
The following code compiles and shouldn't:
struct Foo {
double num;
}
void main() {
Foo[] foo = new Foo[5];
foo[] = null;
}
It then fails at runtime with the following nonsensical error message:
object.Exception: lengths don't match for array copy
Comment #1 by bearophile_hugs — 2010-11-10T12:15:53Z
It's an example of bug 3889
Comment #2 by bugzilla — 2010-11-16T20:13:51Z
null is a valid value for a slice, and the rvalue of the assignment is expected to be a slice. It's a slice with 0 length (which is still a valid slice), and for slice assignment to work the length of the lvalue must match the length of the rvalue. The message is correct - the lengths don't match.
This is working as designed.
Comment #3 by bugzilla — 2010-11-16T20:16:35Z
Bearophile is correct that this is a duplicate of bug 3889, which is an enhancement request.
Comment #4 by dfj1esp02 — 2010-11-16T21:34:06Z
I'd rather say it's a dup of bug 3395.
Comment #5 by dfj1esp02 — 2010-11-16T21:39:09Z
Disambiguation will make it hard to copy empty slices... well... such operation is not needed too much either.
---
foo[]=(cast(Foo[])null)[]; //copy null slice
foo[]=null; //should not typecheck, expected foo[]=Foo(...);
---