Result of attached test code is follows:
----
part1 ----
true, false, false, false, false
true, true, false, false, true
false, false, true, true, false
false, false, true, true, false
false, false, false, false, true
part2 ----
true, false, false, false, false
true, true, false, false, true
false, false, true, true, false
false, false, true, true, false
false, false, false, false, true
part3 ----
true, true, true, true, true
true, true, true, true, true
true, true, true, true, true
true, true, true, true, true
true, true, true, true, true
----
I discovered two issues.
Part 1 & 2:
Shared const should not be implicitly convertible to shared, is it?
Part 3:
All of them are completely broken.
Comment #1 by k.hara.pg — 2010-10-19T04:30:48Z
Created attachment 786
test code
Comment #2 by bearophile_hugs — 2010-10-19T04:58:23Z
By the way, you have just shown the right way to design (or test) a language: you need to test all the items in the matrix/tensor of all possible combinations. One of the the inventor of Java did the same.
Comment #3 by k.hara.pg — 2010-10-19T08:08:39Z
This code should not work.
----
interface I
{
void set(int v);
}
class A : I
{
this(int v){val = v;}
int val = 10;
override void set(int v){val = v;}
}
void change(I i)
{
i.set(100);
}
void main()
{
auto a = new immutable(A)(10);
assert(a.val == 10);
change(a); // immutable(A) is converted to (mutable) I.
assert(a.val == 100); // breaking const-correctness!
}
----
(In reply to comment #3)
> interface I
> {
> void set(int v);
> }
> class A : I
> {
> this(int v){val = v;}
> int val = 10;
> override void set(int v){val = v;}
> }
> void change(I i)
> {
> i.set(100);
> }
> void main()
> {
> auto a = new immutable(A)(10);
> assert(a.val == 10);
> change(a); // immutable(A) is converted to (mutable) I.
> assert(a.val == 100); // breaking const-correctness!
> }
Looks like duplicate of bug 3731 (read Steven's comment).
Comment #7 by braddr — 2011-02-06T15:38:47Z
Mass migration of bugs marked as x86-64 to just x86. The platform run on isn't what's relevant, it's if the app is a 32 or 64 bit app.
Comment #8 by clugdbug — 2011-02-09T08:27:11Z
The patch causes this code to fail to compile:
----
class S { }
void main()
{
S s1 = new S;
const S s2 = new S;
assert(s1!=s2);
}
---
Even so, I think the patch is probably correct -- it's a problem with opEquals.
But this means that more work is required before this patch could be applied.
Comment #9 by schveiguy — 2011-02-09T10:18:44Z
(In reply to comment #8)
> The patch causes this code to fail to compile:
> ----
> class S { }
>
> void main()
> {
> S s1 = new S;
> const S s2 = new S;
> assert(s1!=s2);
> }
> ---
> Even so, I think the patch is probably correct -- it's a problem with opEquals.
> But this means that more work is required before this patch could be applied.
That code should fail to compile on the current compiler without patches, because the prototype for opEquals for objects is:
bool opEquals(Object lhs, Object rhs);
Clearly, this should not accept any const objects. Because opEquals is special somehow, the compiler rams it through.
So yeah, that code is not indicative of the patch being bad.
Comment #10 by yebblies — 2012-01-30T18:13:15Z
*** This issue has been marked as a duplicate of issue 3731 ***