Found on 2.062 on Windows, haven't tested other platforms, but it would presumably be the same. Working version is 2.057. I'm not sure if this is a compiler issue or something in the library instead
int x = 1, y = 2, z = 3;
int *[] a = [&x,&y,&z];
int *b = a;
int **c = a.ptr;
The previous bundle I have reports a no implicit conversion error on the b = a assignment.
The result of this is (b == c) in raw pointer values and (*b == *c == &x), and isImplicitlyConvertible!(int*[], int*) is evaluating to true.
Additional info:
- int*[] can convert to int*, but int[] can't convert to int, so it requires a pointer somewhere
- if I change a from int*[] to int*[3], I get the error I would expect (no implicit conversion)
- it does work for more than one level of pointers, but the type must match (ie int***[] -> int***)
This is causing weirdness in the container templates because pointer usage evaluates to multiple possible templates with isImplicitlyConvertible being broken and is probably the cause of issue 9518
Comment #1 by k.hara.pg — 2013-04-10T21:56:32Z
In D's specification, implicit conversion from T[] to T is not allowed.
The code had accidentally changed to be accepted in 2.061, but the regression was already fixed in 2.062 (Bug 9259 is directly related to the issue).
Therefore, the OP code is invalid and should not work.
Comment #2 by phyphor0 — 2013-04-11T01:32:09Z
Yes, but the problem is it is compiling without error on 2.062 and that breaks stuff
Comment #3 by k.hara.pg — 2013-04-11T01:54:35Z
(In reply to comment #2)
> Yes, but the problem is it is compiling without error on 2.062 and that breaks
> stuff
Oh... I completely had mistaken. Sorry confusion by my wrong comment.
Yes, this is actually a regression. It had occurred from 2.061, and still exists in 2.062.
Fortunately, this regression had been found in the 2.063 devel, and already fixed in bug 9539. You would get the fix in 2.063 release.
Thanks!
*** This issue has been marked as a duplicate of issue 9539 ***