D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 5199 - null implicitly converts to any other type on array assignment
Summary: null implicitly converts to any other type on array assignment
Status: RESOLVED INVALID
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: Other Windows
: P2 normal
Assignee: No Owner
URL:
Keywords: accepts-invalid, diagnostic
Depends on:
Blocks:
 
Reported: 2010-11-10 12:06 UTC by David Simcha
Modified: 2010-11-16 21:39 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description David Simcha 2010-11-10 12:06:42 UTC 
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 bearophile_hugs 2010-11-10 12:15:53 UTC 
It's an example of bug 3889
Comment 2 Walter Bright 2010-11-16 20:13:51 UTC 
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 Walter Bright 2010-11-16 20:16:35 UTC 
Bearophile is correct that this is a duplicate of bug 3889, which is an enhancement request.
Comment 4 anonymous4 2010-11-16 21:34:06 UTC 
I'd rather say it's a dup of bug 3395.
Comment 5 anonymous4 2010-11-16 21:39:09 UTC 
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(...);
---