string[] test() { string[] ret; ret ~= null; ret ~= null; assert(ret.length == 2); // fails return ret; } void main() { enum ctfe = test(); } === test90.d(7): Error: assert(ret.length == 2u) failed test90.d(12): called from here: a()
This works on git HEAD. Probably a duplicate of a recently fixed bug.
Are we sure this isn't expected? I mean a null could mean a null string[], not a null string. string[] ret; string[] a = null; ret ~= a; ret ~= a; neither of these lines should do anything to ret, since they are empty arrays of the same type. I almost think the code in question should fail to compile for being too ambiguous.
See bug 2006.
(In reply to comment #2) > I almost think the code in question should fail to compile for being too > ambiguous. Right.
(In reply to comment #3) > See bug 2006. So is this a dupe? I'm concerned there was a change in git that makes this "work." Moving from one ambiguous interpretation to another doesn't sound like progress. Do we have some definitive answer on what *should* happen?
(In reply to comment #2) > I mean a null could mean a null string[], not a null string. I oversimplified the test - in the original code it came from, it was more like string a = null; ret ~= a; which gets the same result in 2.056 I haven't tried git though. I'm not sure how to use that yet! > I almost think the code in question should fail to compile for being too > ambiguous. With null itself... maybe. In the case of string[], ~= null could have two meanings, but one of them is pretty obviously a no-op, so it's probably not what you meant. If a variable happens to be null, maybe doing nothing is what you wanted, but in that case, the variable has an exact type declared so it's not ambiguous anymore.
BTW, I labeled this as CTFE because in 2.056, running the same function at runtime, the assert passes. I think this worked in CTFE a couple releases ago too, and since it works in the git version again, it was probably just a temporary regression in the interpreter.
This compiled on DMD2.053, but generated wrong code. It failed to compile on 2.054 to 2.056. Fixed 2.057 -- dup of bug 6077 *** This issue has been marked as a duplicate of issue 6077 ***