Bug 2056 – Const system does not allow certain safe casts/conversions involving deep composite types
Status
RESOLVED
Resolution
INVALID
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2008-04-28T19:10:00Z
Last change time
2015-06-09T01:19:24Z
Keywords
rejects-valid
Assigned to
nobody
Creator
bruno.do.medeiros+deebugz
Comments
Comment #0 by bruno.do.medeiros+deebugz — 2008-04-28T19:10:06Z
Const system does not allow certain safe casts/conversions involving deep composite types. In the following example, all casts should be allowed.
----
void testcases()
{
int[][] intArrayArray;
int[][][] intArrayArrayArray;
const(int)[][] f1 = intArrayArray; // Error here
const(int[])[] f2 = intArrayArray;
const(int)[][][] g1 = intArrayArrayArray; // Error here
const(int[])[][] g2 = intArrayArrayArray; // Error here
const(int[][])[] g3 = intArrayArrayArray;
}
Comment #1 by bruno.do.medeiros+deebugz — 2008-05-28T16:09:36Z
I'm not sure if I should open a new bug or not, but since this one is still open, I'll put it here.
The array cases seem to be fixed in DMD 2.14, but the very same problem still exists with pointer types, for example:
void testcases()
{
int** intPtrPtr;
int*** intPtrPtrPtr;
const(int)** h1 = intPtrPtr; // Error here
const(int*)* h2 = intPtrPtr;
const(int)*** i1 = intPtrPtrPtr; // Error here
const(int*)** i2 = intPtrPtrPtr; // Error here
const(int**)* i3 = intPtrPtrPtr;
}
Similar issues also exist for associative arrays.
Comment #2 by bruno.do.medeiros+deebugz — 2010-11-17T12:15:17Z
The latest DMD compiles both code samples now, *however*, I've come to realize that in fact this code should NOT be allowed (that is, any of the "Error here" lines in the code above should produce an error), because these casts are actually not safe.
For the reasons why, see bug #2544 , which is the inverse of this one.
Comment #3 by dfj1esp02 — 2010-11-17T14:21:51Z
So this is a regression?
Comment #4 by bruno.do.medeiros+deebugz — 2010-11-18T04:06:29Z
A regression? Not exactly.
When this bug was submitted, the lines marked with "// Error here" did not compile, and that was the "bug" that was reported. At some point DMD was changed so that the first, and later both code samples above compiled without errors. (I don't know if it was because Walter tried to fix this "bug" specifically, or if it was due to some other DMD changes).
So this "bug" became fixed, but as I found after seeing #2544, this "bug" is actually invalid, and should not have been fixed in the first place.
( For curiosity, it would only be valid if immutable did not exist, or more precisely, if T was the only subtype of const(T) )
Comment #5 by dfj1esp02 — 2010-11-18T12:11:28Z
> When this bug was submitted, the lines marked with "// Error here" did not
> compile
So what does the fix for bug 3621, I wonder? (It's for dmd 2.038)
Comment #6 by bruno.do.medeiros+deebugz — 2010-11-19T15:20:41Z
(In reply to comment #5)
> > When this bug was submitted, the lines marked with "// Error here" did not
> > compile
>
> So what does the fix for bug 3621, I wonder? (It's for dmd 2.038)
I don't know. The code sample in #3621 still compiles ok, so maybe it was a mistake from Walter's part, and the bug is not really fixed. Just like #2544 is not fixed.