Comment #0 by destructionator — 2011-12-01T18:07:38Z
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()
Comment #1 by clugdbug — 2011-12-02T02:57:40Z
This works on git HEAD. Probably a duplicate of a recently fixed bug.
Comment #2 by schveiguy — 2011-12-02T04:30:34Z
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.
Comment #3 by clugdbug — 2011-12-02T04:44:28Z
See bug 2006.
Comment #4 by bearophile_hugs — 2011-12-02T04:48:35Z
(In reply to comment #2)
> I almost think the code in question should fail to compile for being too
> ambiguous.
Right.
Comment #5 by schveiguy — 2011-12-02T04:54:29Z
(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?
Comment #6 by destructionator — 2011-12-02T07:47:17Z
(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.
Comment #7 by destructionator — 2011-12-02T07:53:36Z
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.
Comment #8 by clugdbug — 2011-12-14T08:35:17Z
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 ***